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FOREWORD h]f Chris Earnshaw 


I am pleased to introduce this special issue of the Journal on Network Management 
Systems, which provides an effective sequel to the issue on Network Administration 
produced in October 1990. 

BT has set as its objective the goal of being the leading global telecommunications 
operator, offering world-class telecommunications services. As we move through the 
1990s, we will see a growing pace of change and rapidly increasing complexity. 
Effective support systems which provide efficient automation of service and network 
management are vital to achieving our goal. 

The essential groundwork to steer the modernisation of BT’s UK network support 
systems to enable them to cope with the challenges of the 1990s was laid by the Network 
Administration Task Force (NATF) and the Network Administration Implementation 
Programme (NAIP). Combined with the business process framework created by the 
Strategic Systems Plan (SSP), these initiatives produced the guiding principles for a 
major systems development and roll-out programme, supporting the evolving oper¬ 
ational organisation. 

This programme has already produced major gains from a set of integrated systems 
which are now automating key operations and providing a comprehensive range of 
network surveillance and control functions. 

Similar analyses have been carried out in respect of BT’s international networks and 
its private networking portfolio. In the case of international networks, these are 
converging on the operational framework and support system structure mapped out for 
the UK network. In parallel, the Concert™programme encompasses integrated support 
systems for private network services. 

The next phases of our drive to enhance our capabilities involve the creation of a 
comprehensive service management platform, integration of service and network 
management and the linking of systems on a global basis. 

The combination of these programmes, using the enabling framework of the Co¬ 
operative Networking Architecture (CNA) and powerful skill bases in the Development 
and Procurement Division, is producing an integrated systems platform which will 
enable BT to meet the challenges of services on a global scale. 

Much will need to be done to keep pace with the continuous evolution of new 
services, enabling control of those services directly by customers, and the management 
of a constantly changing global network. 
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Network Management Systems: Introductory ©verwlew 

R. J. HELLEURt, and N. R. P. MILWAY* * 


Significant effort has been made by BTsince the mid-1980s to revise radically the company's approach 
to managing networks. This introductoty article considers the jigsaw of network management support 
systems , the architectures that are used to control its evolution and the complex challenges still to be met. 


INTRODUCTION 

It is increasingly accepted by the leading public 
telecommunications operators (PTOs) that the 
key differentiators in their competitive business 
are the services offered and the efficiency with 
which they manage the networks supporting 
those services. 

Significant effort has been applied in BT since 
the mid-1980s to revise radically the company’s 
approach to managing networks and the systems 
required to automate this activity. 

As a result of the Network Administration Task 
Force (NATF) and the Network Administration 
Implementation Programme (NAIP) which com¬ 
bined headquarters and field views of the way 
forward, together with the Strategic Systems Plan 
(SSP) analysis of the business processes required 
to plan and operate the network efficiently, the 
shape of the target vision is well understood. 

The October 1990 issue of the Journal re¬ 
corded some of the key aspects of this complex 
programme. One such aspect of the programme 
encompasses the systems which support the pro¬ 
cess of operating the network. This special issue 
concentrates on the network management func¬ 
tions and the major computing systems used to 
implement the vision created by the NATF. 

In parallel with these public networking initia¬ 
tives, the essentials of managing private networks 
have been analysed and embodied into the 
Concert™ development programme. Both public 
and private programmes, despite being driven 
with different short-term priorities, are evolving 
within a common technical framework, the Co¬ 
operative Networking Architecture-Management 
(CNA-M). 

Developments are moving rapidly to meet 
these objectives, creating a jigsaw of interwork¬ 
ing pieces which efficiently support ‘flow- 
through’ of workstrings. 

However, several significant challenges re¬ 
main to be met as new services are launched, and 
as the technology and topology of networks 
change. 


t BT Development and Procurement 

* BT Worldwide Networks 


This article considers these challenges and the 
way in which the network management jigsaw 
will evolve to match these changing demands, 
and is intended to act as an introduction to this 
special issue of the Journal. 

THE VISION 

The NATF study led to a rationalised vision with 
the minimum number of integrated operations 
and computer centres, with highly skilled, flex¬ 
ible and mobile technicians and automated work 
management. 

As with Concert™, all networks and network 
elements should be managed by a consistent, 
integrated set of network mana gement systems., 
supporting standardised operational processes 
and workstrings. These highly effective systems 
must be optimised to provide rapid evolution to 
support new products and services. 

FUTURE REQUIREMENTS 

Clearly, BT is continuously driving to offer its 
customers: 

# new services, 

Q reduced charges, 

H improved quality, and 
Q customer control of service. 

In line with other PTOs, BT is also looking to 
a networking future which is significantly differ¬ 
ent from the existing situation, encompassing: 

# virtual private networks, 

# hybrid public and private networks, 

® multi-service networks, 

® global networks, 

# intelligent core network, 

# mobile network periphery, and 

# diverse technologies including synchronous 
digital hierarchy (SDH), asynchronous transfer 
mode (ATM), pair gain, fibre in the access net¬ 
work, and radio. 

Crucial to achieving rapid and flexible service 
provision is the need to integrate network admin¬ 
istration functions fully with service manage¬ 
ment, customer-facing and financial systems. 


168 


British Telecommunications Engineering , Vol. 10, Oct. 1991 









The combination of these initiatives and the 
enormous pace of change being undertaken is 
going to put considerable stress upon the network 
management systems that are now becoming fun¬ 
damental to the effective operation of the busi¬ 
ness. 

RESUME OF NETWORK MANAGEMENT 
FUNCTIONS 

Networks and services must be managed from 
‘cradle-to-grave’, throughout their whole life 
cycle (Figure 1), covering: 

© forecasting, 

• requirements analysis, 

• detailed dimensioning and planning, 

© configuration data management, 

© construction, 
i> work management, 

© inventory management, 

© maintenance and repair, 

# traffic management, 

# capacity assignment and frame management, 

# performance analysis, 

and ultimately iterating to enhancement or with¬ 
drawal. 

The challenge of network management is to 
encapsulate all of these life-cycle functions, to 
allow them to interwork effectively and cover all 
networks. 

ESSENTIAL APPROACH FOR SUCCESS 

An ad hoc, uncoordinated approach to meeting 
the above challenge will not succeed. 

In BT, the fundamental need for cohesion and 
consistency has been recognised both in the organi¬ 
sation of teamworking and the technical solutions. 

Organisation for Success: 

• BT Worldwide Networks (WN) has established 
a view of the way forward by forming strong links 
between field end-users and headquarters coordi¬ 
nators through the NAIP 1,2 . This, through a num¬ 
ber of working groups, has been identifying and 
prioritising areas of improvement. 


Figure 1 

Communications 
management life 
cycles 


@ The improvements targeted by the NAIP, and 
indeed all changes affecting network manage¬ 
ment systems, are channelled through the Net¬ 
work Control Architecture Board (NCAB). This 
body ensures that all system developments follow 
appropriate evolution paths. It is run by the Oper¬ 
ational Policy and Systems (OPS) unit in WN, and 
reinforces team play by encompassing develop¬ 
ment interests from BT Development and Pro¬ 
curement (D&P) and field input. 

% Cohesion of development is achieved by a 
coordinated approach within D&P, with the focus 
and design leadership vested in the Network Man¬ 
agement Department. 

0 For private networks, the cohesion across the 
BT portfolio is achieved by the Concert™ pro¬ 
gramme, under the control of Managed Network 
Services, BT Products and Services Management. 

Technical Cohesion : 

© The essential shape of the processes to run the 
business has been identified in the Strategic Sys¬ 
tems Plan (SSP). SSP is providing vital guidance 
in ensuring that the necessary system interworking 
is identified, and that the appropriate system func¬ 
tional groupings are defined, and provides a tem¬ 
plate to aid the consolidation of the existing 200+ 
support systems into some 40 key systems for the 
future 3,4 . 

® The NCAB has created a vision which em¬ 
bodies: 

(a) end-to-end network management, 

( b ) coverage of the whole network life cycle 
(Figure 1), 

(c) fully integrated functionality, 

(d) flexibility—evolution and growth, 

( e ) high levels of automation/decision sup¬ 
port, and 

(/) conformance to architectural objectives. 

$ The other enabler which allows the jigsaw of 
systems to be put together to meet the vision and 
SSP targets is the architecture—CNA-M 5 . This 
forms the essential framework for integrated sup¬ 
port systems: 

(a) the functions in each jigsaw piece, 

( b ) interfaces between pieces, covering proto¬ 
cols and message sets, and 

(c) an open computing platform. 

© Synergy between public and private network 
management portfolios is being exploited by the 
use of the common CNA-M architecture and the 
common prime contractor focus provided by Net¬ 
work Management Department. 

ENABLING ARCHITECTURE 

The application of CNA-M architecture creates a 
layering of the logic and a functional segmenta¬ 
tion, shown in Figure 2. 

In order to explain the impact and benefits of the 
architectural approach, each element of the archi¬ 
tecture will be described and the way it contributes 
to the success of systems development defined. 
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EIS: Electronic information system 
CARDVU: Charging and routing data verification utility 
LTLA: Long-term log analysis 
NCDB: National charging database 
NETMON: Network monitoring system 


NOMS: Network operations and maintenance system 
NTMS: Network test management system 
NMW2: Network management workstation 
OMC: Operations and maintenance centre 
TNS: Transmission network surveillance 
WMS: Work management system 


Figure 2 

Systems portfolio 


'Business’ Architecture 

This ‘enterprise’ perspective concentrates on 
business process analysis, as employed by the 
SSP. This has defined all of the processes that are 
carried out in efficiently running an advanced 
telecommunication network organisation. By 
examining how these processes are grouped into 
logical systems and how each group of processes 
exchanges information with other groups, so an 
ideal set of systems and interfaces can be defined. 

Network Management Hierarchy 

In parallel with the process view of the support 
systems, a layered view has been defined, prag¬ 
matically grouping systems according to their 
role. Thus service management systems are dis¬ 
tinguished from network control systems and ele- 
ment managers. The architecture and 
implementation of service management is a com¬ 
plex issue in its own right, being the focal point 
between BT’s customers and their interaction 
with the company. Service management is dis¬ 
cussed further in Reference 6, and will be covered 
in more detail in future issues of the Journal. 

Physical Architecture 

The NAIP has created a coherent deployment 
architecture which deals with the physical place¬ 
ment of hardware and people. This includes ten 
network operations units (NOUs), network field 
units (NFUs) and network administration com¬ 
puter centres (NACCs): structures, which are a 
vital part of the overall architecture 1 . 

Interface Architecture 

The interface architecture provides the frame¬ 
work for a communications infrastructure which 
connects users to systems, systems to other sys¬ 
tems for information sharing, and systems to the 
network elements they are managing. 


Key standards for these interfaces are being 
defined in the CNA-M programme, which maps 
and intercepts agreements of the international 
bodies, such as the Open Systems Interconnection 
(OSI)ZNetwork Management Forum and CCITT. 

The interface architecture is supported by 
‘open’ and proprietary products which enable in¬ 
terconnection with other architectures, such as 
IBM’s SNA and DEC’S DECNet. 

Data Architecture 

Data architecture offers the ability to standardise 
what the processes need to talk about. Defining 
the structure and format of the key information 
items provides a common currency which may be 
shared by the complete family of support systems. 

The object-oriented style of the CNA-Man- 
agement communications protocols will force the 
standardisation of objects as well as simple data 
structures. Work is progressing rapidly on crea¬ 
ting the standards in the CNA-M programme and 
external standards bodies like ISO, CCITTf and 
the OSI Network Management Forum. 

System (Computing) Architecture 

The system architecture defines how a particular 
system is constructed, rather than the functional 
role it plays within the jigsaw. This deals with the 
following main components: 

0 computer hardware, 

© operating system, 

© database management system, 

© transaction processing, 

© communications drivers, 

© man-machine interfacing (MMI), and 
Q the application programming interface (API). 


t ISO—International Organisation for Stand¬ 
ardisation 

CCITT—International Telegraph and Telephone 
Consultative Committee 
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There is a drive by the computing industry to 
create standard open interfaces to these elements, 
based on UNIX/POSIX and X Open standards to 
produce the open platform. 

The system developers are also driving to¬ 
wards reusable sub-functions and utilities. 

These two initiatives are being brought 
together in the Generic Systems Architecture for 
BT network management systems. 

Communications Architecture 

In order to provide cost-effective and tailored 
access to systems and network elements by field 
personnel and NOU people, it is essential to con¬ 
struct universal communications networks with 
the flexibility to support, for example, pro¬ 
gressive use of workstations. 

A backbone X.25 packet network has been 
established, with use of common T-NET local 
area and wide area networks. 


THE SYSTEMS PORTFOLIO 

The systems portfolio is outlined in Reference 7. 
The following elements are covered in detail in 
this issue of the Journal , and are shown mapped 
onto the architecture in Figure 2. 

O Switch management: operations and mainten¬ 
ance centre (OMC). 

® Transmission management: transmission net¬ 
work surveillance (TNS), network monitoring 
(NETMON) system. 

^ Alarm management: network operations and 
maintenance system 1 (NOMS1). 

• Local access management. 

Q Test management. 

• Traffic management: network traffic manage¬ 
ment system (NTMS). 

O Performance management: long-term log ana¬ 
lysis (LTLA). 

• Finance management: national charging data- 

p. 3 base (NCDB), charging and routing data verifica- 

Simple service ti° n utility (CARDVU). 

provision—workstring • Work management: work management system 
flow-through (WMS, NOMS2). 



<D Access and security: network management 
workstation (NMW2), electronic information 
system (EIS). 

The remaining functions, particularly plan¬ 
ning, configuration and event management will 
be covered in a future issue. 

The above systems are addressed mainly with 
a public networking emphasis in this Journal. 
However, an outline is also included of the private 
network and service management objectives of 
the Concert™ programme. 

WORKSTRING FLOW-THROUGH 

The essential feature of providing good service to 
customers, and achieving efficient network man¬ 
agement, is to support the main workstrings (se¬ 
quences of tasks) of the business. This requires 
support systems to be linked together electroni¬ 
cally, and the workstrings to be optimised. It 
cannot be achieved by developing systems in 
isolation. This brings a new dimension of linkage 
and effective, automated flow-through , which can 
be illustrated by considering provision of tele¬ 
phony service. 

In Figure 3 for example, the order for new 
service is taken by the operator of the Customer 
Service System (CSS). 

The operator can: 

Q take details of service required; 

O check the availability of resources to provide 
service; and 

Q make an appointment with the customer to 
carry out any work required at his/her premises. 

The CSS system will: 

O send a task to the work management system 
(WMS) to arrange for any customer premises, net¬ 
work, frames or exchange work to be carried out; 

# send a task to the configuration manager with 
details of the service required; and 

O set up billing details. 

The WMS system will: 

# identify appropriate manpower to do work at 
the customer’s premises and put the job in the 
individual’s worklist; and 

# allocate other associated jobs to appropriate 
staff. 

The configuration manager will: 

# send transactions to configure the switch. 

The test manager will: 

# schedule tests on each network element in¬ 
volved and, at the right time, perform the tests. 

Satisfactory test results will mean that the cus¬ 
tomer is provided with service, and billing will be 
started. 

The workstring for service provision is per¬ 
formed by computer systems linked through task 
interfaces. Manual intervention is minimised, and 
is closely defined and scheduled. 
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CHALLENGES 

A strong support structure with high functionality 
is rapidly becoming available, but many issues 
remain to be resolved in the short and medium 
term; for example: 

(a) traffic management in a multi-service net¬ 
work where call priorities, durations, bandwidth 
and quality demands are very different from plain 
old telephony service (POTS); 

( b ) the design/planning implications of vir¬ 
tual private networking, including resilience and 
recovery aspects; 

(c) the significant differences in planning and 
network control required by SDH; 

0 d) the opportunities to add remote surveill¬ 
ance and control to copper local access networks 
with the deployment of pair-gain systems 5 ; 

(e) the easing of management of multi-vendor 
networks as suppliers add open management in¬ 
terfaces to their network elements, and add func¬ 
tionality to their element managers; 

(/) the need to link customer service systems 
with network planning systems and network ele¬ 
ments that are remotely configurable to provide 
immediate service (for example, ‘warm dial 
tone’); 

(g) attainment of a consistent approach across 
local, core and international network manage¬ 
ment systems; 

( h ) management of CCITT No. 7 signalling 
systems in the intelligent multi-service network; 
and 

(/) a quantum improvement in system de¬ 
livery times and costs by making use of computer- 
aided software engineering (CASE) and 
prototyping techniques. 

These issues are discussed further in Refer¬ 
ence 8. 

FUTURES AND EVOLUTION 

The portfolio of systems will evolve into a set of 
generic functions which will be customisable for 
any BT network, and will eventually cover all BT 
network requirements 9 . 

These generic functions will conform to the 
CNA-M architecture, and will interwork via open 
interfaces conversing about commonly defined 
objects and data, and mounted on open computing 
platforms. 

The basic functions will automate the SSP 
processes with interoperability providing ‘flow- 
through’ . 

In addition, new advanced information pro¬ 
cessing technology 10 will allow many more as¬ 
pects of network and service management to be 
automated. 

Throughout the evolution of systems, a bal¬ 
ance must be struck between achieving the bene¬ 
fits to be gained from immediate satisfaction of 
an urgent business need, and the secondary objec¬ 
tives of clean architecture. In time, as the generic 
reusable piece-parts become the norm, these 


potentially conflicting demands will converge; 
solutions will be produced in the quickest and 
most effective way by using architecturally con¬ 
formant solutions. 

Where ad hoc, proprietary network manage¬ 
ment systems exist or are introduced for expedi¬ 
ent reasons, they will (normally) be replaced by 
conformant solutions to achieve long-term cost 
effectiveness from consistency. 

The portfolios for public and private network 
management and service management will 
coalesce, and this will bring the following advant¬ 
ages to customers and the operator: 

Advantages for the Customer. 

O Direct control of network services. 

0 Controlled quality of service. 

# Flexible service management. 

S Rapid service provision. 

Advantages for the Operator : 

0 Cheaper and more-effective network oper¬ 
ation. 

0 Rapid deployment of new services. 

Q Reduced cost of change. 

# Interoperation with wider business processes. 

CONCLUSIONS 

Four years after developing a clear vision and 
architecture for network administration, BT has 
made great progress in its realisation. 

All the major components are now in place and 
are evolving rapidly to meet the target architec¬ 
ture and achieve full functionality. In parallel, the 
new operational centres are opening rapidly. 

While there is much still to be done, BT is now 
very well placed to meet the ever-increasing de¬ 
mands on network management. 
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Cooperative Management: The Key to (Managing Customer 
Networks 

K. J. WILLETTSt 


The art and science of managing some of the most complex systems on earth, the world's telecommuni¬ 
cations systems, is changing rapidly. This article looks at some of the needs of customers in managing 
their networks and some of the solutions that are emerging in the marketplace worldwide. 


INTRODUCTION 

In many markets, particularly those of the triad of 
North America, Europe and the Pacific Rim, net¬ 
worked information systems have become fun¬ 
damental to business activity. Initially, these 
networks were based on leased bandwidth from 
operators and sophisticated customer premises 
equipment. 

With the growth of the liberalised telecom¬ 
munications marketplace of the 1990s, customer 
networks are becoming increasingly complex. 
They comprise products and services from 
multiple suppliers, spanning many parts of the 
world and many time zones. The demands on 
these networks for reliability, capacity and new 
services are rising dramatically. The focus on the 
successful planning, implementation and oper¬ 
ation of complex networks, in other words, man¬ 
agement, has never been greater. 

This article looks at some of the needs of 
customers in managing their networks and some 
of the solutions that are emerging in the market¬ 
place worldwide. 

CUSTOMER MANAGEMENT NEEDS 

Most organisations who need advanced com¬ 
munications networks are not primarily interested 
in owning and operating that network infrastruc¬ 
ture. Their principal businesses are in industries 
as diverse as banking, retailing, travel and trans¬ 
portation. 

As markets have developed internationally, 
organisations have expanded from a national 
base, first into multinationals and then into trans¬ 
nationals. The latter type of organisation not only 
replicates its structure in other countries, but 
places different key functions in different parts of 
the world. It then becomes totally reliant for its 
operation on sophisticated information networks. 

With such reliance on a corporate network 
infrastructure, with such a potential to influence 
company productivity, it is no wonder that these 
organisations should want to build and control 
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these networks themselves. Information systems 
directors are now a common feature of a corporate 
board, reflecting the importance of the network to 
the company. 

The needs of such an organisation are very clear. 
The network must serve the corporate purpose and 
mission. It must be tailored to the needs of that 
organisation in terms of quality, availability, relia¬ 
bility, security and cost. The organisation’s man¬ 
agement must be able to make decisions over 
priority if the network suffers failure or impair¬ 
ment. They must decide on locations served and 
when new services are introduced. To do otherwise 
would give the organisation no competitive advant¬ 
age over its rivals and would put a major area of 
corporate infrastructure outside the managerial 
span of control. 

MARKET TRENDS 

The telecommunications operators around the 
world were, until recently, monopolies either pub¬ 
licly or privately owned. In general, their custo¬ 
mers had little choice and, as organisations, most 
telecommunications providers were not particu¬ 
larly responsive to their customers’ needs. The 
needs of major corporations, growing ever more 
reliant on networked information, went largely 
unnoticed by many traditional operators. This led 
to a huge growth in ‘do-it-yourself’ networking 
by major coiporations during the 1980s. As the 
customer premises equipment businesses were 
liberalised in many countries, many corporations 
leased bandwidth from operators and added soph¬ 
isticated customer premises equipment to de¬ 
velop networks often more advanced in terms of 
features and functions than those of many tele¬ 
communications providers. 

During the late-1980s and early-1990s, the 
market for network services has also begun to 
liberalise, leading to several major trends across 
the world. 

First, the telecommunications industry has 
begun to be market led. No longer will customers 
accept poor quality, long lead times and inflexible 
products and services; they simply go elsewhere. 

Secondly, the marketplace is a multi-vendor 
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one. Many new products are appearing from 
many new suppliers and have increasingly shorter 
life cycles. 

Thirdly, network operators are rapidly intro¬ 
ducing new flexible services, giving customers a 
choice between the ‘do-it-yourself’ approach and 
a managed service owned and operated by the 
telecommunication service provider. 

Finally, and most importantly, the cost base of 
networking has shifted. 

The costs of both customer premises equip¬ 
ment and network services are falling as a result 
of competition and technology advances. Mean¬ 
while, the ‘hidden’ costs (people, facilities, soft¬ 
ware changes etc.) which are a product largely of 
increasing complexity are increasing. This com¬ 
plexity cost is now causing whole segments of 
industry to re-examine their approach to network 
ownership and management. 

Many customer organisations are seeking only 
to buy easily manageable products and services, 
with additional technology to integrate the man¬ 
agement of diverse supplier products into a co¬ 
hesive whole. For example, modem and 
multiplexer procurement choices are now made 
with an increasing emphasis on manageability 
and ongoing costs of ownership rather than sim¬ 
ply price and functionality. 

Other customers are turning to more radical 
network solutions. Many companies, especially 
during the current recession, are looking for a safe 
way out of networking altogether. Purchasing the 
network from a third-party facility manager is 
becoming increasingly popular. The use of man¬ 
aged services, especially on a worldwide basis, is 
also growing rapidly. 


Figure 1 
Control of the 
corporate network 



FLEXIBLE COMMUNICATIONS PORTFOLIO 


MANAGEABLE NETWORK COMPONENTS MANAGED SERVICES 

FOR EXAMPLE, BANDWIDTH SERVICES, FOR EXAMPLE, END-TO-END 

CUSTOMER PREMISES EQUIPMENT MANAGED NETWORK CAPACITY 


Figure 2—Products and services 


LESSONS FOR THE INDUSTRY 

The 1990s will see unprecedented change in the 
structure of telecommunications and the services 
provided. Information systems will continue to 
grow in importance to their user corporations 
whilst the availability of flexible and reliable net¬ 
working will continue to grow dramatically. The 
ongoing management of the information system, 
maximising its value to the corporation whilst 
minimising its costs, will be of paramount import¬ 
ance. 

It is also clear that management will be an 
increasingly cooperative activity between the 
user organisation, the information system pro¬ 
vider and the network provider. For the telecom¬ 
munications industry, these trends will dictate 
some rethinking and repositioning of their pro¬ 
ducts and services. Customers need control over 
their vital asset—the corporate communications 
system. They will exercise that control in two 
dimensions—who owns the network asset, and 
who manages it (see Figure 1). 

Successful network operators will be those 
that listen and respond to their customers’ net¬ 
work needs. Today and into the mid-1990s, cus¬ 
tomers are demanding flexibility of ownership 
and manageability in tailored packages to meet 
their changing business needs. This demands a 
flexible portfolio of products and services which 
network operators are now beginning to promote 
(see Figure 2). 

Those corporations who wish to continue 
building and operating their own networks in¬ 
creasingly will demand manageable network 
components. Others will want a smooth and safe 
migration to a point where a network operator is 
running all or part of the customer’s network and 
taking care of extensions, upgrades, changes and 
so on, for a predictable fee. Some customers, for 
example, may want to retain operation of the data 
network, but use an outside source to provide the 
voice network, or they may want to run the North 
American segment of the network, but use an 
outside source to provide the European nodes. 
The split may be based on different criteria; for 
example, the time of day. 

Finally, a customer may want to contract the 
entire provision and operation of the network to 
a managed services operator. 

SERVICE LEVEL MANAGEMENT 

In the case of a customer contracting all or part of 
the network to a network operator, the agreement 
will be based on agreed services for a known cost. 
This type of service level agreement is common 
and often exists as a paper contract. Increasingly, 
however, the customer does not want a ‘fixed’ and 
static agreement, but will want to dictate service 
levels for various network applications. For 
example, very high service levels for high-value 
applications, such as an on-line reservation sys¬ 
tem, may be required, and much lower (and hence 
lower cost) service levels for less vital functions, 
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with the ability to switch these priorities depend¬ 
ent on business demand. 

The customer will want to dictate the locations 
to be served and the capacity between those 
nodes, and may want to alter the price/perfor¬ 
mance mix of the network by time of day/year or 
geography. 

This type of flexible service needs an elec¬ 
tronic form of service level management between 
customer and network operator. In order to imple¬ 
ment these requests, the operator (and customer, 
if continuing to operate part of the network direct¬ 
ly) needs an integrated structure between this 
service view of the network and the network itself 
so that control can be exercised with minimal 
human intervention. This leads to a layered archi¬ 
tecture for the management of customer networks 
and complex management information which 
flows between the customer and the operator (see 
Figure 3). 



Figure 3—Integrated managed network 


This architecture becomes more complex as 
the management of the network is split into do¬ 
mains. There may be several separate spheres of 
control in an overall information system. These 
must be interconnected at least at the service 
management level. Examples are the local area 
network infrastructure, the wide area network and 
the end computing and application infrastructure. 
Each of these may be further partitioned between 
various managers such as the customer and the 
operator (see Figure 4). 



SYSTEMS/APPLICATIONS 

MANAGEMENT 







LOCAL AREA 
MANAGEMENT 


NATIONAL/GLOBAL 

WIDE AREA 
MANAGEMENT 


Figure 4 —Management domains 


END-TO-END MANAGEMENT IN 
PRACTICE 

There is a staggering number of combinations of 
network type, supplier, product or service and 
management domain owner in a global informa¬ 
tion network. Consequently, the highly flexible 
systems and architecture required to meet this 
need are sophisticated and at the leading edge of 
today’s technology. 

There are several key points that must be taken 
into account. Management systems must be ca¬ 
pable of supporting the following characteristics: 

Interoperation : There will be many islands of 
management control and data in a system, which 
must be able to share information when re¬ 
quired. 

Distributed data : Data is held in many forms, 
in many places across an information system. 
This data must be capable of being viewed as one 
logical whole. 

Flexibility of deployment: No two networks 
will be alike and no two customers will require 
the same management infrastructure. Systems 
must be very flexible in their design and im¬ 
plementation at all levels, data structure, manage¬ 
ment applications, user interfaces and physical 
deployment. 

Portability and scalability: Networks vary 
tremendously in size. Different customers have 
different computing policies. Management sys¬ 
tems must be very flexible in their ability to 
mount on a wide range and scale of computing 
platforms. 

Cooperation between vendors of information 
system components is extremely important if the 
various domains of management are to integrate 
successfully and thus permit true end-to-end man¬ 
agement. 

This cooperation is not based on altruism, but 
sound commercial needs. No single company glo¬ 
bally produces the range of products and services 
to supply an entire information system. Even if it 
did, most customers prefer competitive purchas¬ 
ing and multiple sourcing. Thus, for a product to 
be viable, especially internationally, it must be 
able to fit into an overall management scheme. 

This cooperation comes about at several le¬ 
vels. Many companies have natural business part¬ 
nerships and cooperate regularly on business 
issues. At the other end of the spectrum is the 
limited cooperation of the national and interna¬ 
tional standards organisations. A new phenome¬ 
non helping to foster industry cooperation on vital 
interfacing issues has been the rise of industry 
consortia in recent years. One such organisation, 
the Network Management Forum, is dedicated to 
promoting interoperability between different 
management domains. Using open systems meth¬ 
ods where possible, this group of over 100 com¬ 
panies from 17 countries has made great strides 
in accelerating the availability of interoperable 
products to meet the rapidly growing needs of the 
marketplace. 
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MANAGEMENT SYSTEMS OF THE 
1990 s—BT’S CONCERT™ APPROACH 

These trends are strongly influencing the forward 
direction of many major players in the networked 
information systems industry. As an example, BT 
has embarked on a comprehensive strategy to 
meet its customers’ management needs in the 
1990s. This programme, begun in 1989, has 
yielded a broad management platform from 
which to meet the widely varying and changing 
customer requirements. 

The Concert™ programme has four key objec¬ 
tives to meet BT customers’ needs. 

© It has built a comprehensive architecture for 
manageability in information networks. This 
architecture, forming a cornerstone of the com¬ 
pany’s Cooperative Networking Architecture, is 
now mature and widely recognised as one of the 
most advanced and comprehensive in the world. 
Many of its concepts and structures have been 
adopted into the work of the Network Manage¬ 
ment Forum, the European Telecommunications 
Standards Institute, CCITT and the International 
Standards Organisation. 

# The Concert™ programme is building this 
architecture into a family of networking products 
and services that are manageable in a common 
way. Engineering development and field trialling 
are now well advanced and these products will 
begin to appear during late-1991. 

# The Concert™ programme is delivering a 
comprehensive capability to integrate various do¬ 
mains of management into a single view of the 
network. This view can be partitioned in many 
ways allowing hybrid management between the 
customer and operator. 

® The Concert™ programme is building a range 
of cooperative alliances with other suppliers. 

The Concert™ ‘Partner’s Programme’ ensures 
that BT networks can interconnect to, and ex¬ 
change management information with, many of 
the customer’s other suppliers. 

CONCERT™ TECHNOLOGY 

Figure 5 

Applications Concert™ is a highly flexible and modular system 

architecture base for the 1990s. Its technology addresses complex 



issues such as distributed databasing, advanced 
graphics and artificial intelligence. The system is 
based on open standards, where possible, and uses 
the base shown in Figure 5. 

Hardware utilisation is flexible and the system 
is currently implemented on Sun Microsystems’ 
Sparc 2 range and IBM’s RS6000 series distributed 
workstations range for customer premises applica¬ 
tions. Larger fault-tolerant platforms are utilised for 
functions supporting major networks. 

Concert’s internal architecture is also flexible. 
It is an object-oriented design consisting of four 
key sub-structures (see Figure 6). 


GRAPHICAL USER INTERFACE 


MANAGEMENT APPLICATIONS 


DATABASING AND PARTITIONING 


ACCESS MODULES 


Figure 6—Concert™ internal architecture 


There are several access modules to interface 
to external systems, ranging from a full Open 
Systems Interconnection (OSI) object-oriented 
protocol and message structures, to proprietary 
and de facto interfaces. 

Databasing is via the Structured Query Lan¬ 
guage (SQL) interface to the ORACLE database. 
Comprehensive sieving and filtering of informa¬ 
tion is supported which enables a wide range of 
views of incoming or stored data to be performed. 
This allows Concert™ to meet the flexible im¬ 
plementation demands of customers. 

Applications use this data to construct user 
information. Concert™ uses a fully-defined func¬ 
tional architecture based on an expanded OSI 
model. Functions such as event handling, re¬ 
source management and configuration manage¬ 
ment are handled in initial releases. 

Finally, there is a comprehensive user inter¬ 
face system based upon XI1 (XWindows) stand¬ 
ards. This is a highly featured graphics interface 
using zooming techniques to show multiple net¬ 
work views and information. The system can be 
tailored to user needs and contains a context-sen¬ 
sitive help system. 

COOPERATIVE MANAGEMENT 

The market trends overviewed earlier indicate 
that the traditional ‘public’ and ‘private’ split of 
telecommunications is rapidly changing. New 
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Figure 7 

Span of management 
requirements for 
communications 

systems 


virtual network services are emerging whilst 
many user organisations are re-evaluating their 
need to own and operate their private networks. 
This is leading to a ‘utility’ and ‘tailored’ segmen¬ 
tation rather like suits off the peg or from a Saville 
Row tailor. 

However, when the communications package 
is designed and delivered, it is likely to be a 
mixture of some customer premises equipment 
and one or more increasingly sophisticated net¬ 
work services. The management of that package 
must span the entire system, across local, national 
and international boundaries and across the 
numerous vendors’ systems that are likely to be 
deployed (see Figure 7). 

In addition, the management of this communi¬ 
cations package is likely to be a shared activity 
between network operator and the customer: in 
other words, a cooperative activity between the 
two. This sharing will need to be on a tailored 
basis but typically, most customers will want to 
concentrate on the business and service manage¬ 
ment aspects (see model shown in Figure 3), 
whilst the network provider handles the oper¬ 
ational issues of managing the network on a day- 
to-day basis within agreed service levels (see 
Figure 8). 


BT’s Concert™ programme is designed to pro¬ 
vide the management platform that will deliver 
this end-to-end view of the network, partitioned 
to suit the customers’ needs. Compatible technol¬ 
ogy is being deployed both within BT’s network 
and on the customers’ premises. This cooperative 
platform provides great flexibility in how the 
management can be shared and, if required, BT Fi ure 8 
can provide a complete managed service with Focus of 
minimal customer involvement in the process. management activity 
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Figure 9 

Concert™ service 
management 



Alternatively, the customer can have a high 
degree of control over all or part of the network 
partitioned on a geographic, time, network do¬ 
main or management layer basis (see Figure 9). 

CONCLUSIONS 

The art and science of managing some of the most 
complex systems on earth, the world’s telecom¬ 
munications systems, are changing rapidly. This 
is not change for the sake of change, but is being 
brought about by fundamental restructuring of the 
telecommunications marketplace and by the 
growing needs of customers to tailor these ser¬ 
vices to meet the needs of their businesses. 

Communications management is both auto¬ 
mating and becoming unlocked from its isolated 
islands into full end-to-end spans of control, 
whilst the network operator and customer are 
starting to share that role in a variety of ways. 

Understanding customer needs and translating 
these into deliverable management features and 
functions has never been so complex and so im¬ 
portant. BT is rising to these challenges and the 


Concert™ programme is well on its way to de¬ 
livering its capability across the globe. 
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Serwice Management Systems 

F. N. SINNADURAIt and G. MORROW* * 


Customers are making increasing use of a wide range of services with a variety of customer equipment. 
To meet these growing customer demands, an integrated service management concept is being developed 
with the emphasis on providing familiar andfriendly customer access. This article outlines the philosophy 
of integrated service management and shows, by use of examples, how different operations are handled 
by the service and network control layers. 


INTRODUCTION 

Telecommunications has moved on considerably 
from just providing the plain old telephone ser¬ 
vice (POTS), to an increasingly varied and soph¬ 
isticated set of services which require integrated 
management. 

Use of telecommunications facilities, and their 
importance to businesses, has increased to such 
an extent that customers need a wide variety of 
services provided either solely from the public 
network or as a hybrid with some element of their 
own equipment. In either event, telecommunica¬ 
tions has reached a turning point where customers 
require control and choice over the services they 
use and seek to use. Hence the emphasis today is 
on integrated service management and customer 
control. 

From the customers’ point of view, this is the 
ability to access information on all their services 
and control them worldwide, whatever their entry 
point into BT. This is not a single geographical 
access point, but is a form of ‘one-stop shop’ in 
that they will receive a consistent and helpful 
reception irrespective of the point of origin of the 
request. 

The concept of service management places 
emphasis on the customer-facing functionality of 
network services compared with the predominant 
emphasis, until recently, on the management of 
network equipment 1 . At the service level, control 
and management of the services does not require 
detailed knowledge of the underlying network, 
just the knowledge that an adequately functioning 
network platform is available. 

This article gives an outline of the service 
management architecture and some of the current 
systems being developed, and gives some exam¬ 
ples of the way in which service and network 
management layers will interwork. Emphasis is 
placed upon the way in which customers will be 
given visibility and control of services within 
contracted service level agreements. 
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These are early days in the creation of inte¬ 
grated service management—future articles will 
explain more detail as the work unfolds. 

SERVICE MANAGEMENT 

The Cooperative Networking Architecture for 
Management (CNA-M), which is the enabling 
framework for successful interworking of all 
BT’s communication management technology, 
has defined a number of layers of logic (for 
example Reference 2) to support the complex 
task of managing the BT communications busi¬ 
ness. (See Figure 1.) 



Figure 1—Cooperative Networking Architecture 
(Management) 


The layer which primarily deals with the logic 
associated with the services, service level agree¬ 
ments, and customer access and control, is the 
service management layer (SML). 

The SML, which is responsible for managing 
customer service, reports its effectiveness into the 
business management layer (BML). The BML 
has the authority and facility for managing the 
business, particularly administering business fa¬ 
cets such as payroll, accommodation etc., and 
monitoring the meeting of key service and finan¬ 
cial targets. The SML obtains its network services 
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from the network control layer (NCL) which is 
described elsewhere in this issue of the Journal L 
The SML must manage a service level agree¬ 
ment (SLA) for each customer, covering a basket 
of services. 

The SLA clearly covers the basic telecom¬ 
munications service, or set of services, and the 
‘support’ framework for each service, including 
provision times, repair times, maintenance char¬ 
ges, reliability and error rates etc. It also includes 
the basic charge for each service, volume dis¬ 
counts and special pricing across the basket of 
services. In addition, the guarantees of quality and 
performance, and the associated penalties have to 
be understood and recorded. 

Therefore, the SML must offer facilities for a 
customer to pick, price and agree the options 
which form the SLA. It must then set up all the 
telecommunications and support services through 
the network control layer. From this point, the 
SML must monitor performance levels to ensure 
that a quality service is provided in accordance 
with the SLA. 

Finally, the SML must provide controlled ac¬ 
cess by the customer to allow interrogation of 
billing or performance information, and to initiate 
service reconfiguration where this is allowed by 
the SLA. 

Thus, service management is supportive of, 
and nearer to, the core of a customer’s business 
activity. In addition, it is the first point of contact 
with a customer from which the telecommunica¬ 
tions provider ensures that the service offerings 
are configured, manipulated and monitored either 
by the customer or on the customer’s behalf—it 
ensures customer control and choice. 

Figure 3—Service management outline design Architecture 

BT has identified seven functional areas that are 
needed to serve the complete life cycle of provid¬ 
ing telecommunications network services to its 
customers. (See Figure 2.) In the architectural 
hierarchy, these functions recur with different 
emphasis in the different layers, as described in 
subsequent sections. 

The tasks within the SML can be summarised 
as the ability to: 

Q provide and create 

# monitor and inform 

• maintain 
® account for 

the services of each customer. 

Analysis of the detail of these tasks has re¬ 
sulted in a process-based view which is encapsu¬ 
lated in the outline design in Figure 3. 

CNA-M then gives a common framework, 
shown in Figure 4, in which the layers of service 
management and network control can operate. 
The functional architecture provides the consist¬ 
ent basis to allow interworking between the layers 
and reuse of components. The outline design for 
service management will be realised within the 
seven-segment view of management functions. 
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Figure 2—Functional areas 
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FUNCTIONS 


SOME EXAMPLES 


The functions at the SML comprise the manage¬ 
ment functional areas, which are generic to the 
CNA-M, as well as service specific applications. 

The generic functions are outlined below. 

© Access control and security are primary re¬ 
quirements to ensure that customers and the net¬ 
work are safeguarded at each level of access (see 
later section on Access Control). 

© Configuration management at the SML deals 
with handling of the customers’ orders, issuing 
appropriate commands to the network layer for 
implementation and reporting to the customer. 
The functions can include new provisions, num¬ 
ber changes, name changes, moves (of people or 
terminal locations). 

# Resource management deals with the assem¬ 
bly of the services in a coherent way, keeps track 
of schedules and creates the inventory from cus¬ 
tomer requests and implementations. 

© Planning and design management accesses the 
inventory to aid the customer in planning new 
services or extending existing ones. 

© Performance management ensures that the 
service is being offered with the correct quality— 
response time, error rates etc. 

© Event management services customer reports 
on faults and problems and has the responsibility 
to pursue the action through the NCL, and to 
report on progress. Faults arising in the network 
are reported up to the SML only if they are service 
affecting; an example is presented later. Events 
affecting billing are also reported to financial 
management. 

© Financial management reconciles the cus¬ 
tomer’s requests, inventory, schedules and usage 
of network services with the tariffs, charges and 
discounts derived from the service level agree¬ 
ment reached between the customer and BT. 

ACCESS CONTROL 

As the number and complexity of available ser¬ 
vices increases, it is essential that customers are 
able to continue to understand and retain familiar 
control of the services they require. This necessi¬ 
tates common access and consistency across the 
full portfolio of services. 

The manner in which customers can have access 
to manage their services can be either direct or 
indirect. (See Figure 5.) Direct access can be from 
a simple terminal on the customer’s premises or, if 
they wish to manage both their services and have 
integrated management across the full range of 
their equipment and services, they would use a 
Concert™ terminal. Alternatively, and for back-up, 
customers can contact the BT service centre to give 
their requirements or to seek help. 

Customer access into the SML is controlled by 
a strict security regime to ensure only authorised 
access to that particular customer’s agreed fa¬ 
cilities. There is also security control between the 
SML and the NCL in order to safeguard the net¬ 
work. 


Consider some examples of customer-oriented 
activities which illustrate the operation of the 
SML and the NCL, and their interaction. 

(a) A customer with a Centrex service re¬ 
quests the allocation of a directory number to a 
named person to be actioned at a certain time and 
date at a particular location. 

The SML accesses the service providing the 
directory number related to the location, sche¬ 
dules the provision and sends the necessary con¬ 
figuration command to the NCL. 

The appropriate function at the NCL identifies 
the switch that should provide the line, interro¬ 
gates it to ensure the connection can be provided 
and if necessary finds alternative solutions and 
resolves contention. The subscriber records sys¬ 
tem database in the operations and maintenance 
centre (OMC2) would be addressed from the 
NCL to determine the circuit allocation and the 
main distribution frame (MDF) wiring that would 
be necessary. Where there is pre-provisioning of 
wiring pairs, then configuration would be im¬ 
plemented. Where local connection is found to be 
necessary, then an appropriate request would be 
sent through to the work management system 
(WMS). 

If the required schedule can be met, then the 
SML and the customer will not know of any 
underlying operations in providing the service, 
the customer will simply receive a message from 
the SML that the request has been met. If there are 
any problems in providing or scheduling the ser¬ 
vice, then this will immediately be flagged to the 
customer indicating alternative choices and offer- Figure 5 
ing planned dates. Customer access 



CSS: Customer Service System NLC: Network level controller 

NOU: Network operations unit SLC: Service level controller 
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(b) If a multiplexer or a bearer link fails, the 
network would attempt to circumvent the prob¬ 
lem by rerouting. The fault would be deemed to 
be service affecting only if the service could not 
be rerouted within the network. 

The fault having been intercepted and handled 
at the lowest management level, the information 
to the next level up (the NCL fault manager) will 
be to report the need to replace the faulty multi¬ 
plexer or repair the link. 

As the event (fault) would not have been 
service affecting, the SML and the customer 
would not be made aware of the occurrence or 
cure of the fault. If the fault were service affect¬ 
ing, then the NCL would prioritise the repair 
activities requested in its message to WMS, 
according to the requirements of the service 
level agreement for that service. In addition, it 
would open a dialogue with the SML by repor¬ 
ting on the likely effects on service. 

(c) Figure 6 shows the architecture of intelli¬ 
gent network (IN) systems providing service 
management functions. 

For a new customer to IN services, the SML 
supports the provision of initial customer profiles 
and enables them to be read or modified from an 
appropriate terminal. 

Where the customer desires to create or 
amend access to their services, the service man¬ 
agement system enables this through the service 
creation environment. By means of service cre¬ 
ation, the network services provider may create 
‘if, then’ management of the customer service 
on the customer’s behalf. Calls may be rerouted 
Figure 6 according to time of day (for example, ‘if’ after 

Intelligent network 6pm, ‘then’ reroute to number wxyz ), number of 
layered architecture rings (after x rings, then divert call to nntm). 



priority of caller, and so on. The SML can also 
control access to and from service providers (for 
example, 0898 suppliers), for instance, mana¬ 
ging call screening for selective connection of 
calls to them. 

Management is implemented through control 
files, and data is then downloaded to the service 
control point which provides specialised call pro¬ 
cessing for those calls routed to it by the service 
switching points. The service creation environ¬ 
ment enables new services to be created over 
pre-provided connections to the customer. 

CURRENT SYSTEMS 

As an introduction to service management, a brief 
review of some existing systems is given. A later 
edition of this Journal will return to the subject of 
service management in more detail. 

Service Management Supporting the 
Concert™ Programme 

Concert™ provides a capability for integrating 
the customer’s management of the services pro¬ 
vided by individual elements of a network, be 
they public, private or hybrid. It is creating a 
cohesive set of developments using the same 
basic technologies and is based on international 
standards for network management. Thus, it is 
capable of interfacing with, and thereby integrat¬ 
ing the management of, products and services 
from many suppliers. 

Current plans include service management in 
managed network systems (MNS), private cir¬ 
cuits, global network services and interfacing 
with virtual private networks. 

The current developments in the Concert™ 
programme conform to the CNA-M architecture 
described above. Each of the network elements is 
interfaced into the Concert™ integrated (net¬ 
work) management system (IMS), enabling the 
full range of management functions to be applied 
to the various elements which may be operated in 
concert to provide and control a particular ser¬ 
vice. 

The customer interface handling for both 
customer premises equipment and public network 
services would be managed from a common ser¬ 
vice management system. Information on 
service-affecting events and performance is re¬ 
ported to the SML which correlates the informa¬ 
tion and takes action according to the service level 
agreement reached with the customer. For in¬ 
stance, the customer may want to be notified if a 
circuit fails for more than five minutes, or may 
have an agreement with BT that there will be a 
reduction in charging if there is a break in service 
greater than an agreed length of time. These 
agreements are enforced by the SML. 

Consistent service management features will 
be presented to users for both private and public 
network services. The service management sys¬ 
tem also includes the billing system where char¬ 
ges are calculated according to an agreed tariff 
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negotiated with the particular customer. The ser¬ 
vice management system enables customers to 
have electronic access to their account informa¬ 
tion and inventory, and to make enquiries of 
ServiceDesk (a help desk support system), so 
providing a rich set of functions which, for 
example, allows the customer to review bills or 
have them delivered at specified intervals. 

Access to the service management system and 
ServiceDesk allows the customer to request or 
cease services and to report faults on-line. Owner¬ 
ship of the fault report is retained by the service 
management system which pursues the repair re¬ 
quest, via IMS, until the fault is remedied. The 
customer, therefore, has access to the status of 
appropriate fault handling. 

The Concert™ terminal provides the customer 
with a full-colour graphical map of the logical 
network, and can use colour to show changes in 
status of services. 

Customer Service System 

For POTS services, BT has in place a very 
effective Customer Service System (CSS) 
which provides service management and inter¬ 
faces into the network to ensure the POTS ser¬ 
vices are provided and monitored, and bills are 
issued as appropriate. 

CSS enables a customer’s order to be taken by 
telephone or at a shop and entered and processed 
by an operator at a terminal. At the same time, the 
customer’s telephone book entry is created auto¬ 
matically. Customer records are managed with a 
facility to locate customers by name, address, tele¬ 
phone or account number. By virtue of being inte¬ 
grated, CSS also keeps track of customer account 
management and billing. 

CSS also has strong functional links into the 
NCL: 

0 for service provision, it configures the net¬ 
work, via the OMC2, and launches the workforce, 
via WMS; 

# in the event of a fault being reported by a 
customer, CSS can initiate line test action and 
register the fault with the NCL fault and repair 
management functions. 

CSS is an example of a large service manage¬ 
ment system, having to cater for the vast majority 
of BT’s customers. 

Service Level Controller 

The service level controller (SLC) has been de¬ 
veloped to support both the Concert™ offerings 
and public network services. It provides terminal 
access for the customer either through a Con¬ 
cert™ graphics screen or through a simple user- 
friendly character screen. Access is security 
controlled according to terminal and personnal 
identification number (PIN) together with other 
safeguards at the interface to the underlying net¬ 
work. SLC functionality includes: 

access security, 


configuration, 

inventory, 

resource management, 
event/fault handling, and 
performance management. 

Implementation of the functions is governed 
by the requirements for the services for which the 
SLC is used. 

Currently, the SLC is being rolled out, for 
example, to provide status monitoring for private 
circuits. 

COMMON TECHNOLOGY 

Service management shares an architectural and 
technological basis with network level manage¬ 
ment systems. Some of the key aspects are intro¬ 
duced in this section. 

At the computing level, this can be identical 
with the open platform used at the NCL, encom¬ 
passing common 

© database management, 

® human-computer interfacing, 

® communications drivers, 

# transaction processing, and 

• operating system (POSIX). 

In addition, many of the components of the 
applications software can be common, as they 
have to make reference to common services, net¬ 
work elements, etc., called objects. 

This ‘object-oriented’ approach encourages 
standard definitions of these objects, their at¬ 
tributes and the actions that can be carried out 
upon them. In this way, it greatly facilitates soft¬ 
ware reuse. 

A top-level object at the SML would be the 
service level agreement. Within this there may 
be a number of feature agreements. Underlying 
this at the SML, for instance, a private circuit 
would be represented as the logical links from 
premise to premise, or the link capacity. At the 
network layer, the link may be represented by 
the physical routing. The definition of service 
objects is a topic that is currently being studied. 
As many as 600 object classes can be identified 
for the more complex services such as virtual 
private services. 

The composition of the full network manage¬ 
ment hierarchy shows that the objects relating to 
a particular service function are mapped from one 
layer to the next. (See Figure 7.) This enables 
efficiency of design whereby an object modelled 
at one layer will require only marginal effort to 
integrate it into the next. 

For instance, a generic fault manager which 
accumulates, correlates, filters, reports and insti¬ 
gates repair can undertake these functions direct¬ 
ly at the NCL for network elements. The objects 
modelled at the NCL are reusable and integrated 
into the SML. However, the functionality and 
emphasis at the SML is to report and pursue only 
events that are service affecting, as described 
earlier. 
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Figure 8—Service management across several operators 


Common technology may be shared not only 
within a network management hierarchy, but may 
also be shared between cooperating networks 
provided they conform to the same architecture 
and standards. This has already been made clear 
in the discussion on architecture and is illustrated 
in the reuse by BT for both customer premises 
equipment managed by Concert™ and the public 
network services, both of which use SLC func¬ 
tionality for service management. 


THE FUTURE 

The evolution of service management function¬ 
ality will enable a rich vein of services to be 
provided and managed within a single telecom¬ 
munications network and even across many tele¬ 
communications network providers. This 
capability is facilitated by the adoption of a com¬ 
mon architecture, CNA-M, and open interfaces 
across and between the management layers. 

Where a service makes use of other networks 
and services, then the architecture provides for 
nesting of the network services. Thus, a princi¬ 
pal service may comprise a number of under¬ 
lying services (each having its network 
attributes and architecture) treated as network 
elements supporting the principal service. The 
architectural model that results is illustrated in 
Figure 8. The actual layers at which the depend¬ 
ent architectures interface will depend on the 
conformity of the principal and subservient 
architectures to open standards (where they 
exist). Where open common management infor¬ 
mation protocol (CMIP) interfaces are used, 
then peer-to-peer service management interac¬ 
tions can also be implemented (see Figure 8). 
Thus, services from many providers and across 
international boundaries may be integrated and 
managed in this way. 

Service management is progressively being 
integrated over the range of services provided by 
BT, including integrated management of both 
private and public (that is, hybrid) networks. 

In support of the Concert™ programme to 
integrate the management of new customer 
premises equipment products and services as 
they are acquired, a set of message interfaces is 
being developed. The messages are based on 
defined Network Management Forum standards 
and, where possible, the suppliers are being 
encouraged to develop and provide the inter¬ 
faces. 

Service management is being progressively 
rolled out, becoming increasingly seamless at the 
interface with the customer for all services. The 
diversity in management systems is also being 
rationalised towards a common integrated archi¬ 
tecture and technology, as described in this 
article. Thus, customers will be able to manage 
their own equipment and interact electronically 
with the full range of BT services through one 
Concert™ IMS located on their premises; that is, 
‘one stop for shopping and control’. 


British Telecommunications Engineering, Vol. 10, Oct. 1991 


185 














































































ACKNOWLEDGEMENTS 

We gratefully acknowledge the contributions of 
our colleagues whose invaluable technical devel¬ 
opments have enabled the construction of this 
article and whose diagrams we have liberally 
drawn on in providing illustrations. In particular, 
we thank Bill Chapman, Roger Parker, Graham 
Turner, John Helleur and those who worked in 
compiling the Concert™ technical literature. 

References 

1 Helleur, R. J., and Milway, N. R. P. Network 
Management Systems: Introductory Overview. Br. 
Telecommun. Eng., 10, Oct. 1991 (this issue). 

2 Oppenheimer, R., and Whittaker, B. P. Man¬ 
agement of Information Technology Services, ibid ., 
Jan. 1991, 9, p. 241. 

3 Customer Managed Communications, Technical 
Overview. Published by BT, 23 April 1990. 


Biographies 

Nihal Sinnadurai is Manager of Advanced Services 
Management Section in the Service Management Divi¬ 
sion of BT Laboratories. His responsibilities are pri¬ 
marily in developments in service management, in 


configuration of network-based services, and in the 
interworking between the layers of network manage¬ 
ment hierarchy for BT’s network products and services. 
Nihal worked as an international consultant for a num¬ 
ber of years providing strategic technology advice to 
international companies in the USA, Japan and Europe. 
He returned to work for BT in 1986 to take charge of 
the computer-aided engineering strategy for circuit and 
system design. His experience includes design, relia¬ 
bility and testability from the component through to 
system level. Nihal holds a Ph.D. in reliability engin¬ 
eering, an M.Sc. in semiconductor physics, and a B.Sc. 
in physics. He is a Fellow of the Institute of Physics and 
a Senior Member of the IEEE. 

Gerry Morrow is manager for the Service Management 
Programme in BT Products and Services Management. 
He has responsibility for working with the network 
service providers to provide service management. Cur¬ 
rent programmes includes Syncordia, GNS, RACE 
(PBX alarms) and Communications Facilities Manage¬ 
ment. He joined BT in the Liverpool Telephone area 
and worked on transmission systems in the Area and at 
BT Laboratories until 1977 when he joined the Prestel 
team at Martlesham. In 1983, after doing research into 
distributed computing, he joined Merlin, the newly 
formed product arm of BT. He has held a number of 
posts in product management, usually concerned with 
the introduction of new products. He holds an M.Sc. in 
Computer Studies, and is a Member of the IEE. 


186 


British Telecommunications Engineering , Vol. 10, Oct. 1991 


SwBtcii Management- The Operations and (Maintenance 
Centre 

H. G. AMBLER, C. H. SCOBIE, and V. W. BALDWIN! 


Modernisation of the switching and transmission networks does not, in itself provide the full range of 
benefits available to the network operator or the customer An efficient and adaptable switch management 
system is required to meet the ever-changing demands on the network. This article outlines the 
development of the operations and maintenance centre that plays a key role in the management ofBTs 
digital switches . 


INTRODUCTION 

It has long been recognised that the modernisation 
of the switching and transmission network ele¬ 
ments would not alone result in a quality and 
cost-effective network. The increasing expecta¬ 
tions of BT’s customers are not limited to the 
availability of new products and services, they 
also demand that the service provider has an 
operational capacity to provide and maintain the 
new services rapidly, with ever-increasing effi¬ 
ciency. The operations and maintenance centre 
(OMC2) plays a key role in enabling BT to meet 
this objective by managing all of its digital swit¬ 
ches. 

Overview 

The OMC2 enables BT to centralise its digital 
telephone exchange maintenance and administra¬ 
tion activities for a wide range of catchment areas, 
up to two million exchange connections. 

The system receives alarms and fault reports 
from exchanges which it stores and forms into 
prioritised work schedules, offering facilities for 
tracking and recording the resolution of each 
problem. Maintenance personnel also have ac¬ 
cess to an inventory of all exchange equipment 
including available spares. 

In addition, administration staff are given ac¬ 
cess to advanced databases covering customer 
service records and network connection records, 
to enable the exchange to be managed remotely. 

The OMC2 offers ergonomically-designed 
human-computer interfaces which enable staff to 
operate consistently on different exchange types. 
It is a highly secure system and provides many 
audit facilities as well as access control. 

The system currently supports both the Sys¬ 
tem X and AXE 10 exchange families, and far¬ 
ther exchange types can be added in the future. 

Importance to BT 

The OMC2 development has been a vital enab¬ 
ling activity in BT’s massive digitalisation pro¬ 
gramme. It is not possible to manage very 


t BT Development and Procurement 


complex modem exchanges without a sophisti¬ 
cated support system of this type. No digital tele¬ 
phone exchange (and BT Worldwide Networks 
(WN) is currently commissioning two local ex¬ 
changes per day) opens for service unless it is 
parented on an OMC2. 

The system has enabled WN to centralise its 
exchange maintenance workforce, assisting with 
necessary efficiency and quality improvements. 
This gives WN the benefits of consistent oper¬ 
ational methods, associated with the freedom to 
operate a multi-vendor exchange purchasing pol¬ 
icy. 

The importance of the role of the system can 
best be gauged by the continuing demand for 
more facilities to be added since the original 
specification was met in 1984. These new func¬ 
tions are being added every six to eight months, 
with enhancements currently planned through to 
1992. 

By reusing 60% of the software engineered for 
the OMC2, other vital support systems such as the 
transmission network surveillance system 1 , and 
the network level controller for the optical-fibre 
systems used by business customers (flexible ac¬ 
cess systems, FAS/NLC), have been spawned. 

HISTORY 

The need for support systems to administer and 
maintain the new digital switches was identified 
early in the System X development programme. 
The local administration centre (LAC) 2 was the 
first attempt at a computer-based operational sys¬ 
tem to manage the then developing digital swit¬ 
ches. The LAC was based exclusively on 
System X technology and used a processor de¬ 
veloped for the small/medium local exchange. 
The resulting support system was designated the 
operations and maintenance centre 1 (OMC1) 3 . 

Early operational experience with OMC1 
identified significant deficiencies, particularly in 
managing the local exchanges. In an attempt to 
meet the urgent needs of the local exchange man¬ 
agers, the basic OMC was developed and de¬ 
ployed by using the BT Factories multi-user 
multi-processor (MUMP). This was always con¬ 
sidered an interim solution, and in parallel with 
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its development, work was in hand defining 
OMC2 to provide an effective long-term means 
of managing the digital switches being deployed 
in the local network. 

After definition and BT Main Board approval 
in 1983, OMC2 was the subject of competitive 
tendering. There followed a period of parallel 
development with two contractors, during 
which a field trial took place. Shortly after¬ 
wards, the (now) Network Management Depart¬ 
ment (NMD) of BT Development and 
Procurement (D&P) emerged in 1985 as the sole 
development contractor. During that same year, 
OMC2 first entered operational service at Bed¬ 
ford, Hull and Bristol, the latter as a result of a 
decision by the then National Networks to adopt 
a cost-reduced version of OMC2 called the 
operations and maintenance unit support sys¬ 
tem to manage its digital trunk exchanges. By 
1988, some 50 systems had been installed at 
sites throughout the British Isles. 

The development of OMC2 has been a conti¬ 
nuing process as the range of products, services 
and types of duty supported has increased over 
the years and the operational processes refined. 
Today, OMC2 uses over 70 DEC VAX computers 
housed in the 10 network administration com¬ 
puter centres (NACCs), and supports 13*5 million 
lines on System X and AXE 10 digital local ex¬ 
changes and the 56 digital main switching units. 
It is used by over 12 000 BT staff throughout the 
country who have access to one or more of the 20 
different duties. 

The total cost of the OMC2 project was £98M 
to March 1991. This is within the authorised 
budget and includes the development costs of 
under £20M. To date, savings have been of the 
order of £500M. 

SYSTEM OUTLINE 

OMC2 is a network support system that provides 
a single point of interface with digital exchanges 
(see Figure 1). It enables users remotely to control 
and manage exchange resources, recognise and 
report faults, perform diagnostics, and undertake 
a variety of other management functions. Oper¬ 
ational staff can perform maintenance, customer 
service and many other duties by manipulating 
resources in the exchanges and by accessing the 
databases in both OMC2 and the exchange. 

OMC2 consists of an operations and mainten¬ 
ance system (OMS) and an independent alarm 
handling system (AHS). 

Facilities 

OMC2 aims to hide the complexity and diversity 
of the control interfaces of the digital switches 
from the operational staff so that customer ser¬ 
vices can be defined in a user-friendly high-level 
way. It automatically translates these high-level 
requests for service into the detailed low-level 
commands needed to provide these services on 
the switches. The performance of this type of 
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function is critical in meeting the expectations of Figure 1 

BT’s customers, and is shown by the statistics for OMC2 overview 

the provision of a five-line PBX (see Table 1). 

For this operation, OMC2 has delivered a major 
improvement over the manual provision time 
whilst simultaneously releasing skilled engineer¬ 
ing personnel to perform more appropriate ac¬ 
tions for BT’s customers. 

These advanced system-design principles 
have allowed the OMC2 to meet the evolving 
needs of the operational units, providing cost- 
effective solutions to their customers’ require¬ 
ments. 


TABLE 1 

Provision of 5-Line PBX 


System 

Date 

Elapsed Time 
hh:mm:ss 

Keystrokes 

Manual 

1985 

1:30:00 

350-650 

OMC/D 

1986 

0:15:00 

25-27 

OMC/E2 

1987 

0:09:00 

25-27 

OMC/F2 

1988 

0:03:00 

25-27 

OMC/I1 

1989 

0:02:00 

25-27 

OMC/J1 

1990 

0:01:07 

25-27 


OMS Man-Machine Interface 

The man-machine interface (MMI) is a user- 
friendly menu and form-based system that offers 
a consistent interface across a range of duties and 
exchange types. Transactions can be completed 
synchronously while the user waits, or executed 
in background mode leaving the user’s terminal 
free for other work. Automatic job control and an 
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indicator reporting progress gives the user infor¬ 
mation on the status of jobs which can be acti¬ 
vated immediately or at some future date and time 
determined by the user. 

OMS Access Security 

The security of access to the OMS is determined 
by: 

0 a passcard to enable the terminal, and 
© a valid user identity and password. 

OMS Communication Links 

User terminals can be linked to the OMS by a 
variety of methods: 

0 V.24 using direct connections with speeds up 
to 9-6 Kbaud, line drivers, statistical multiplexers 
or auto-answer modems; 

0 T-NET and Ethernet local area networks 
(LANs); or 
# X.25 network. 

Exchanges are connected to the OMS by syn¬ 
chronous X.25-based communication protocols. 

Exchange Configuration and Data 
Management 

Accessed via the MMI, a number of software ap¬ 
plications allow the user to manage both AXE 10 
and System X exchange elements. These applica¬ 
tions cater for the in-service configuration of ex¬ 
change customer and routing data, either 
individually or in bulk. The MMI protects the user 
from the difficult man-machine languages 
(MMLs) used to operate the exchange systems. 
On-line validation of user-entered data is carried 
out automatically against configuration data held 
in application databases such as the subscriber 
record system. Information on the status of ex¬ 
change resources (for example, directory numbers, 
equipment numbers etc.) is held within the data¬ 
base and is available for automatic allocation, re¬ 
source summaries and management statistics. 

Unsolicited Report Handler 

The OMS obtains raw maintenance information 
in the form of unsolicited reports from exchanges. 
It has facilities to receive and recognise reports of 
many different types and to store them in the 
maintenance database. Reports that are con¬ 
sidered serious enough to generate maintenance 
tasks are termed active and stored in an exchange 
work list. A maintenance officer is alerted at his 
terminal if an active report is associated with an 
alarm event in an exchange. 

Alarm Handling System Outline 

The AHS (see Figure 1) is an independent micro¬ 
processor-based system capable of collecting and 
displaying alarms from a variety of sources. It 
provides an immediate summary of all alarm repor¬ 
ting locations, and monitors the alarm collection 


equipment. The AHS also supports the concentra¬ 
tion of alarm reporting for out-of-hours working. 

Implementation 

OMC2 is a modern system constructed on the 
principles of data-driven flexible design to allow 
evolutionary tracking of the exchange moderni¬ 
sation programme. 

OMS Capacity 

The OMS has been designed and implemented to 
handle a catchment area with the following par¬ 
ameters: 


Numbers of 

Exchanges 30-50 

Exchange connections 2 000 000 
User codes 250 

Simultaneous users 60-100 


OMS Hardware 

The OMS is based on DEC VAX computers, each 
OMS being tailored to meet the needs of individ¬ 
ual installations by exploiting the available VAX 
hardware options of processor power, periphe¬ 
rals, cluster architecture and communication in¬ 
terfaces. 

OMS Software 

The application software is written in the C pro¬ 
gramming language and makes sophisticated use 
of the facilities provided by the VAX/VMS opera¬ 
ting system. Database services are provided by the 
VAX utilities such as the DEC record management 
system and the ORACLE relational database man¬ 
agement system. 

SYSTEM DEVELOPMENT AND 
EVOLUTION 

Drivers for OMC2 Changes 

The pressures to enable OMC2 to support new 
builds and services have, in the past, been consid¬ 
erable and continue to grow. The incentives for 
such change include: 

Customer Services Increasingly, the busi¬ 
ness wishes to capitalise on the increased flexi¬ 
bility of the new digital switching systems by 
introducing new services and product lines. In 
many cases, the new services are complex and can 
only be administered and maintained automat¬ 
ically. In other cases, there are strong economic 
advantages for doing so. 

Faster Provision of Existing Services There 
is also the business need to provide existing 
services faster. The automation of provisioning 
activities is one way in which this can be 
achieved. 

Network Switching Development The 
OMC2 must be capable of interfacing with any 
new exchange release. Of paramount importance 
is the continued compatibility with all facilities 
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and services supported on earlier exchange 
builds. OMC2 must also support any additional 
services provided by any new exchange build. 

Operational Administration and mainten¬ 
ance procedures are constantly being refined in 
the light of operational experience. Often it is 
appropriate that OMC2 should be enhanced to 
support the new procedures. 

Technology Exploiting the improvements in 
the hardware and proprietary software used by 
OMC2 can generate optional changes which re¬ 
sult in a more economic and powerful system. 

Architecture Fundamental design of OMC2 
was completed in the mid-1980s, and it is this 
architecture which often determines the rate at 
which OMC2 can be enhanced and the cost of 
doing so. Changes to the architecture have been 
and are being made to intercept a generic system 
architecture embracing the concepts of the 
Strategic Systems Plan (SSP) and the Coopera¬ 
tive Networking Architecture-Management 
(CNA-M). 

Release History 

The evolution of OMC2 has been managed by a 
series of carefully planned software releases. To 
date, there have been 14 major builds, each of 
which have contained a large number of develop¬ 
ment changes. The builds are listed in Table 2 
together with their major facilities and the oper¬ 
ational date. 

Project Management 

The development of OMC2 over the past five 
years has been a process of continuous enhance¬ 
ment to meet changing business requirements. 
The need to control this process has resulted in 
the evolution of a specialised project manage¬ 
ment methodology which focuses on the control 
of change. This has enabled changes to the pro¬ 
duct to be undertaken by separate teams working 
in parallel, improving BT’s ability to meet the 
tight timescales often imposed by the business 
requirements. 

The content of any proposed OMC2 build is a 
compromise. The development effort necessary 
to implement all the requests for change in any 
one build far exceeds the resources available. A 
proportion of the requests will be essential to 
ensure the continued compatibility of OMC2, or 
to provide facilities to meet regulatory issues. The 
remaining requests for change included in any 
proposed build are determined by their relative 
business priorities and benefits. 

OMC2 is a large development utilising the 
skills of over 100 engineers. The success of the 
project and the continued high quality of the 
product would not have been possible without the 
commitment of the engineers involved and the 
excellent, open and honest, working relationship 
that has been established between developers, 
project management and customer repre¬ 
sentatives. 


TABLE 2 

OMC2 Release History 


Build 

Major Facilities 

Date 

A 

OMS field trial 

85 

B 

System X SEP1 maintenance, administration, alarms 

10/85 

C 

Subscriber record system 

4/86 

c+ 

Multicluster SEP1 

7/86 

D 

AXE phase 1 maintenance administration, alarms 

10/86 

El 

System X SEP1 DDI and macros 

3/87 

E2 

AXE 10 phase 1 large processor 

6/87 

F 

System X SEP2 distributed communications 
SEP1-SEP2 upgrade 

9/87 

G 

System X SEP2 X.25, ISDN, improved maintenance 



inventory system 

AXE 10 subscriber record system 

5/88 

H 

AXE 10 phase 2 subscriber record system, X.25 

System X multiline IDA, exchange stats processing, 

2/89 


PASTE database link to Oswestry 

6/89 

11 

AXE10 phase 3A, System X builds, 



London code change 

12/89 

12 

AXE 10 multiline IDA, enhanced fault data for IDA 



customers, phase 1 OMS and OMUSS rationalisation 

7/90 

J1 

AXE10 phase 3B, AXE10 inventory system 



Canary Wharf, IMUX line hunting 

11/90 

Jle 

Exchange data management system 

3/91 

J2 

Communication and transaction processing architecture 



Intelligent network support 

10/91 

K1 

OMC2/CSS interface 



Tariff group charging 

2/92 


Development Cycle 

The key activities in the development of any 
OMC2 build are shown in Figure 2. The develop¬ 
ment cycle from specification to full release ex¬ 
ceeds 12 months. If new releases are to be available 
at 6 monthly intervals there has to be a considerable 
overlap. At any given time, build (N- 1) may be 
involved in integration and testing, build N may be 
at the coding stage, whilst the specification and 
early design work is in hand for build (N+l). Such 
a complex development strategy requires careful 
planning and management of manpower, develop¬ 
ment tools and testing environment. 

Test Strategy 

The test strategy currently in use for OMC2 is 
based on a verification, validation and testing 
approach. It consists of formal reviews of speci¬ 
fication and design, informal code trials, and a 
series of graduated test stages. Module and sub¬ 
system tests are performed by the implementation 
teams, followed by integration and system test. 
The new release is then trialled at pilot sites under 
the supervision of the Product Supply Group prior 
to its general release. 

Specification and design reviews are used (for 
testing purposes) to ensure testability and to 
check conformance to specified requirements. 
Code trials are used to verify that the code pro¬ 
duced is correct, both in form and content. 
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Figure 2 
Overlapping 
development cycles 
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8 

9 

10 

11 

12 


CODE/UNIT TEST BUGFIX 

RELEASE AM * * * \ 

INTEGRATE/TEST ^ | 

[rELEASE TO FIELD 


-► IDENTIFY CANDIDATE CHANGES 

-► PROBLEM ANALYSIS AND SPECIFICATION KEY CHANGES 

SYSTEM SPECIFICATION ^-► DELIVERY PLAN 


DESIGN/TEST SPECIFICATIONS 
BUG FIX 
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RELEASE «+1 
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SYSTEM SPECIFICATION 


DELIVERY PLAN 


Integration testing takes place only when the 
implementation team has demonstrated that the 
new or changed facility works correctly. 

System testing only takes place when a final 
build is available, including all changes success¬ 
fully integrated, for a release. The objectives of 
this phase of testing are to ensure that facilities 
added later in the integration phase have not ad¬ 
versely affected those added earlier, and that the 
new functionality has not had any unforeseen 
effects on the rest of the system. 

NETWORK ADMINISTRATION 
COMPUTER CENTRES 

NACC Establishment 

The Network Administration Task Force (NATF) 
report 4 identified considerable advantages in con¬ 
centrating the computer support systems needed 
to manage the network in a small number of large 
centres around the country. A subsequent and 
more detailed study determined that the optimum 
number of centres was 10 and proposed suitable 
sites. Board authority was successfully sought to 
establish the 10 NACCs and a fallback centre, and 
to consolidate the then operational OMC2s, of 
which there were over 50, into the NACCs. 

The objectives set by the Board were achieved 
within budget and three months ahead of sche¬ 
dule. Detailed planning was the key to the success 
of the project. The many activities, which in¬ 
cluded preparation of accommodation, provision 
of communication systems, installation and com¬ 
missioning of computer hardware, and the expor¬ 


ting of operational databases for reload at the 
newly established NACCs were carried out with 
the minimum of operational disturbance. Staff 
from the NACCs, D&P, WN Headquarters and 
DEC contributed to the success. 

Dimensioning 

Having established OMC2 at the NACCs, it was 
essential to monitor performance and, more im¬ 
portantly, estimate the future demands on the 
systems and establish budgets for additional hard¬ 
ware that would maintain an acceptable level of 
performance. The requirements for processing 
power, storage etc., are determined by many fac¬ 
tors which are constantly changing. They include 
the number of digital lines to be managed, the 
numbers and types of user, changes to the OMC2 
software, communication systems in use, etc. A 
dimensioning document, produced and regularly 
reviewed by D&P, is available for OMC2. With 
each NACC system manager providing details of 
the future operational environment, it is possible 
to estimate changes that are necessary to maintain 
operational effectiveness. A yearly cycle, invol¬ 
ving NACC, D&P and WN Headquarters staff is 
now well established whereby future hardware 
requirements can be assessed, budgets estab¬ 
lished, orders placed and expenditure monitored. 

Software Roll-out 

Roll-out of enhanced OMC2 software releases 
now follows a well established release procedure 
that has been developed over the last five years. 
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As a new release reaches the final stages of 
system testing, an early release is taken by the 
OMC Product Support Group (PSG) to test the 
upgrade procedure that will ultimately be per¬ 
formed at all in-service operational sites. This 
testing is performed within a captive model envi¬ 
ronment at the switching systems test facility 
(SSTF) located at Martlesham Heath. 

The upgrade procedure and the new software 
with its new or enhanced facilities, is then loaded 
onto a live system within an operational NACC 
as a pilot site trial. 

Upon satisfactory completion of pilot site 
trials, with agreement and authority of the cus¬ 
tomer, the new build is replicated and distributed 
to individual NACCs by die PSG. 


agement will be provided within a coordinated 
architecture. 

For example, links with problem manager 
workstation will allow a network-wide view of 
fault reports, and will provide advanced user- 
interface facilities. Work management functions 
currently provided on OMC2 will migrate to the 
work management system, WMS(N) 6 , and 
generic piece parts for fault management, corre¬ 
lation etc., will be used more as OMC2 changes 
to become the switch domain manager in the 
network control layer. 

As part of the continuing evolution of OMC2, 
the following changes are being made to the im¬ 
plementation architecture. 

Transaction Processing 


Support 

All requests for day-to-day support are handled 
by the OMC PSG front office via a central contact 
telephone number. Details of each enquiry are 
recorded upon a fault database to enable fault 
history and progress to be monitored, and appro¬ 
priate corrective action taken by support engin¬ 
eers. Out-of-hours support is provided on a 
24-hour rota basis, 365 days of the year. 

Reliability 

Maximum resilience to points of failure has al¬ 
ways been a major consideration in the system 
design of OMC2. Typically, systems in the field 
achieve total availability of between 98-99-75%. 
This excludes planned down time for mainten¬ 
ance activities. 

Fallback 

The total loss of an NACC would cause massive 
disruption to the services BT provides to its cus¬ 
tomers. Contingency plans, enabling services to 
be maintained with the minimum of disruption, 
have been established in the form of an oper¬ 
ational resilience facility commonly known as 
fallback. If such an event were to occur, proce¬ 
dures have been developed such that centralised 
maintenance of the network/administration fa¬ 
cilities can be provided by OMC2 systems located 
within the fallback centre at BT Laboratories, 
Martlesham Heath. 

To test these procedures, live fallback prac¬ 
tices have been accomplished without loss of 
service from NACCs at Glasgow and Belfast. It 
is planned to test fallback procedures regularly for 
each operational NACC site on a regular basis. 

FUTURE DEVELOPMENTS 

The growing complexity of telecommunications 
management is such that it is insufficient to con¬ 
tinue developing support systems which tackle 
only part of the management task in isolation 5 . 
Although the benefits of a standalone OMC2 can 
be demonstrated, the need for efficient network 
management means that, in future, switch man¬ 


The recent development of a core applications 
support system based on a transaction processing 
(TP) model provides a base from which future 
applications requirements can be met cost effec¬ 
tively. The TP approach also facilitates the adop¬ 
tion of the workstrings approach to complex 
network management requirements described in 
the SSP. 

In combination with the facilities offered by 
the current and planned communications devel¬ 
opments, TP provides the means by which the 
OMC2 system can be made ‘open for business’, 
becoming an active participant in the integrated 
community of network management systems of 
the future. 

Communications 

The existing communications facilities restrict 
the hardware architecture for each OMC2 instal¬ 
lation. The potential for major cost savings 
through enabling systems to share machines more 
flexibly has led to the provision of a new com¬ 
munications architecture, the Common Com¬ 
munications System (CCS). 

CCS provides symmetrical inter-process com¬ 
munications, via a standard interface, between any 
two OMC2 applications in a NACC, and a set of 
integrated gateways for onward communications 
to exchanges. A simple name service relieves the 
applications from the need to be aware of the 
physical location of the destination, thus facilitat¬ 
ing increased distribution of OMC2 functionality. 

CCS is currently being extended to provide 
communications between OMC2 and other sys¬ 
tems. These activities are strongly based around 
the Open Systems Interconnection aspects of 
BT’s CNA-M, and includes both common man¬ 
agement information service (CMIS) and file 
transfer, access and management (FTAM) capa¬ 
bilities. 

Data Handling 

Specialised database engines will be provided to 
cope with the increasing demand for data process¬ 
ing and storage. They will also open up the data 
to external systems, allowing the development of 
a single logical network management database. 
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CONCLUSION 

The OMC2 project is a good example of the large 
software contracts undertaken within BT to pro¬ 
vide high-quality network management. From the 
outset, it has been a highly visible strategic project 
with a sequence of very demanding milestones 
which have kept the team under considerable 
pressure throughout. 

Very few competing systems offer the ability 
to achieve centralised maintenance and manage¬ 
ment of several types of exchange equipment. 
Because of the complexity and proprietary nature 
of current switch management interfaces, the op¬ 
portunities for organisations other than switch 
vendors or major telecommunications operators 
to develop a solution is exceedingly small. No 
significant examples are known to cover econ¬ 
omically a range from a few thousand to two 
million exchange lines, providing a full set of the 
necessary functions. 

OMC2 remains a very competitive system 
which continues to provide benefits to BT in 
improving the quality of the network while reduc¬ 
ing operational costs. It would be hard to conceive 
of the network modernisation programme with¬ 
out such a system. 
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Transmission Surwelllance in BT Worldwide Networks 

G. HART, R. M. GALLAGHERt, S. R. MOOR, and T. H. M. McKENZIE* * 


In recent years , centralised transmission network sutyeillance has been given a high profile within BT. 
This article describes the transmission network surveillance system, TNS, and also looks at NETMON, 
a system which emerged from a number of practical field initiatives. The history and experience of using 
these systems is reviewed, together with their future evolution and integration with other network 
management systems within BT’s portfolio of systems. 


INTRODUCTION 

Some significant steps have been taken over the 
past decade to modernise and improve the tech¬ 
nology used in the BT network, driven by the need 
to improve quality of service, reduce costs, and 
make available new products and services to cus¬ 
tomers. Significant improvements have also 
taken place in the way in which this network 
technology is operated and managed by BT, espe¬ 
cially in the switching environment. The advent 
of processor-controlled switches paved the way 
for tools such as the operations and maintenance 
centre (OMC2) and alarm handling systems 
(AHS) which have enabled radical changes in 
operational procedures, compared to analogue 
units. Surveillance and fault diagnostics, and in 
some cases rectification, can now be performed 
remotely from centralised operation and mainten¬ 
ance units, and the maintenance workforce can be 
directed and managed in a way which benefits 
customer service. This has resulted in a large 
reduction in operational costs whilst sustaining 
the focus on quality of service. 

In contrast, the introduction of digital trans¬ 
mission technologies did not enable such proce¬ 
dural changes to be realised at the outset. The 
operational facilities of transmission equipment 
supplied on the world market tended to mimic 
analogue practices which relied on manned sta¬ 
tions, with people available to respond to and 
manage on-site alarm conditions with no cen¬ 
tralised control. The scale and cost of providing 
centralised surveillance for transmission is higher 
and more difficult to justify than for switching 
systems, due to the larger number of equipments 
and sites involved, coupled with wide geographi¬ 
cal spread. A number of initiatives developed by 
field staff led to a basic surveillance system 
known as NETMON , first deployed in 1985. 

A consultancy study undertaken in 1986 indi¬ 
cated that there would be significant financial 


t BT Worldwide Networks 

* BT Development and Procurement 


benefits from deploying a much more powerful 
transmission network surveillance (TNS) system 
on a national scale. The conclusions of the Net¬ 
work Administration Task Force (NATF) also 
highlighted the need for TNS as part of a plan to 
rationalise network management and control and 
reduce operational costs. The NATF recommen¬ 
dations led to the Network Administration Im¬ 
plementation Programme (NAIP), which has 
established the operational template for World¬ 
wide Networks based on ten network operations 
units (NOUs). TNS is a key enabler alongside 
OMC2 within the NAIP programme for the con¬ 
solidation of network management and control, 
and work management into each of nine NOUs. 

In 1987, the BT Management Board auth¬ 
orised the capital expenditure required to retrofit 
centralised transmission surveillance facilities to 
the existing base of digital transmission technol¬ 
ogy in the network over the period 1988-92, and 
to enable developments to ensure that all future 
growth could be accommodated. Initial plans for 
a collaborative development with AT&T were 
eventually aborted in favour of an internal devel¬ 
opment programme, now being undertaken by the 
Network Management Department of BT Devel¬ 
opment and Procurement as part of the evolving 
network control layer. 

The thrust of the TNS programme consists of 
two parallel activities: the first is a concentrated 
deployment of monitoring infrastructure to maxi¬ 
mise surveillance coverage; the second is a focus 
on phased development of the system to provide 
incremental functionality changes in line with 
operational needs. 

This article begins by tracing the history of 
TNS and NETMON, and pinpoints the key busi¬ 
ness benefits these systems provide to BT. It looks 
briefly at the way in which the systems are cur¬ 
rently used in the field, and then describes the 
main functions and architecture of TNS andNET- 
MON, together with the next development steps 
currently being undertaken. Finally, it gives an 
indication of the various factors influencing cur¬ 
rent thinking on the evolution of these systems. 
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HISTORY AND BACKGROUND 

NETMON emerged from a consolidation of a 
number of practical initiatives in the Manchester 
and Scotland Districts. Scotland’s initiative was 
to monitor the input to chart recorders from digital 
radio and line equipment with low-cost home 
microcomputers. This idea eventually led to the 
displacement of chart recorders, each costing 
hundreds of pounds. Manchester District’s propo¬ 
sal involved capturing muldext frame alignment 
alarms. These alarms indicate loss of service to 
customers, but are often of such short duration 
that they are virtually invisible to conventional 
station alarm equipment. NETMON became 
operational in 1985 and incorporates both of these 
original ideas, as well as a number of other prac¬ 
tical suggestions gleaned from direct field experi¬ 
ence of transmission operations. 

However, NETMON was not designed to cope 
with the demands of national network surveill¬ 
ance. These demands include: 

O coping with large-scale deployment of trans¬ 
mission systems; 

® the potential high cost of ownership of the 
communications infrastructure; 

the requirement to gather performance man¬ 
agement information in order to facilitate a more 
proactive management of the transmission net¬ 
work; and 

# the requirement to integrate network surveill¬ 
ance systems with other network management 
systems, including work management. 

The TNS project was originally conceived to 
overcome these limitations. Its origins go back to 
June 1986, when the first generation of trans¬ 
mission monitoring systems (TMS) was developed 
to manage the BT outer core (junction) network. 
The system used about 60% of the software, and 
the same hardware platform as the existing switch 
maintenance system, OMC2. In February 1987, 
TMS Phase 3 was given a pilot trial in Manchester. 
After further development and extensive trials, the 
subsequent system, TMS Phase 4, received its 
operational beta test in London during early-1990. 
TMS Phase 4 was enhanced and released as an 
operational system in July 1990, and development 
was completed in November 1990, when the TMS 
project objectives were met. 

Subsequent work is now being performed 
under the TNS programme, starting with the first 
release TNSO. 1. Further releases of TNS software 
will incorporate key facilities and user require¬ 
ments captured from direct field experience. 

BENEFITS OF NETWORK 
SURVEILLANCE 

The key business benefits of network surveillance 
are: 


rapidly pinpointing failures and deterioration as 
they occur. This in turn leads to a reduction in 
short breaks and improved circuit reliability. Ana¬ 
lysis of data from NETMON can, for example, be 
used to produce a league table of the most faulty 
circuits, providing the opportunity either to 
switch customers to better circuits and/or to target 
investigation on troublesome circuits. 

Q Improved manpower efficiency due to im¬ 
proved prioritisation and direction of the work¬ 
force. 

# The ability of staff to use network surveillance 
systems to correlate alarms so that the source of 
multiple alarms is accurately diagnosed. 

THE PORTFOLIO OF NETWORK 
SURVEILLANCE SYSTEMS 

The surveillance of a variety of transmission net¬ 
work elements such as digital multiplexers, line 
and radio systems is the responsibility of the 
Transmission Operations and Maintenance Unit 
working in the NOU. By necessity, this role in¬ 
cludes liaising with other maintenance staff in 
order to bring faults to the attention of field staff, 
and controlling out-of-hours attendance at remote 
sites. These units also act as single-number fault¬ 
reporting points, so that fault reports on Mega- 
Stream and KiloStream circuits can be passed 
from BT customer-facing units for diagnosis and 
clearance. 

The monitoring of these network elements is 
performed automatically using NETMON, TNS, 
and the alarm monitoring systems Gateway and 
network operations management system 
(NOMS1) which monitor simple station-based 
alarms. These systems generally operate inde¬ 
pendently, although there is a field initiative to 
develop a simple interface which will enable the 
passing of TNS alarms to NOMS1. 

The way in which these systems are currently 
used within the NOU environment is shown in 
Figure 1. 

The following sections describe the TNS and 
NETMON systems. 

TNS SYSTEM DESCRIPTION 

The TNSO. 1 build provides a comprehensive sys¬ 
tem for the surveillance of transmission network 
elements. This requires the handling of trans¬ 
mission alarms, and the monitoring of trans¬ 
mission performance from a large number of 
elements. While OMC2 manages a smaller set of 
complex network elements (stored-program-con- 
trolled exchanges), TNS faces the challenge of 
collecting, collating, processing, and displaying 
information from a vast array of less complex, 
physically dispersed components. 

System Architecture 


# Improved quality of service achieved by being Each TNS host processor serves a given catch- 

able to eliminate consequential fault reports and ment area defined by the NOU in which it is 

_ located. The host processor is used as a stand- 

t Multiplex/demultiplex equipment alone system housed in a network administration 
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computer centre (NACC), and accessed remotely 
by NOU personnel. The system uses a two-tier 
hierarchy (see Figure 2) of: 

Q data collection network 
@ operations support system (OSS). 

In addition, the communication infrastructure 
links the OSS and the data collection network. 

This architecture is based upon data collect 
equipment located at the equipment stations, and 
a central computer located at the NACC. With the 
current TNS0.1 build, the central computer sup¬ 
ports up to some 200 stations, and 50 000 sys- 
tems|. Later builds will support a larger number 
of stations and systems. 

Data Collection Network 

The transmission network presents a significant 
challenge to any data collect system. It has to cope 
with a very large number of alarm points and 
stations/locations. In addition, it has to be cost 
effective. These criteria were major drivers for the 
TNS0.1 data collect equipment. As a result, a 
number of key features were incorporated in the 
data collection network design. These include: 

© low-cost interface circuits, supplied with new 
equipment provisions; 

® retrofit capability; and 


t In the traditional sense, each system refers to a 
network element or an ‘alarm point’. 

* This interface unit has no capability for capturing 
performance error data. 


# high system capacity. 

The data collection network consists of inter¬ 
face units, and primary collect equipment (PCE) 
shelves. In order to provide data collection and 
forwarding for the different generations of trans¬ 
mission systems currently in the field, interface 
units provide connectivity in four ways, which 
are, in order of preference: 

(a) via an embedded monitoring interface 
within the transmission equipment as part of the 
supplied element; 

(b) via a retrofitted replacement alarm card 
called a network surveillance interface unit 
(NSIU) provided for monitoring equipment with¬ 
in each shelf; 

(c) via a digital signal monitor network ele¬ 
ment (DSMNE) used to monitor early copper line 
systems for 2 Mbit/s monitoring, normally em¬ 
ployed to monitor private circuits (maximum of 
16 transmission systems); and 

(i d) as a last resort, via an input/output network 
element (IONE) using a shelf alarm isolator. This 
is generally used for simple transmission equip¬ 
ment alarms* (maximum 32 alarm points); for 
example, shelf, rack or suite alarms. 

The above elements are polled by a primary 
collect processor (PCP) every second for raw 
alarm and performance data. Data collection is 
provided by a duplicated, multi-drop HDLC bus 
(RC8245 - RS485 bus) which forms a daisy chain 
linking NSIUs, IONEs, DSMNEs and PCP on the 
PCE shelf. This bus is cost effective, and uses its 
own BT proprietary message and protocol defini- 



Figure 1 
Transmission 
surveillance 
systems in 
operation 
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tions. Any alarm state changes or definable per¬ 
formance threshold exceptions are immediately 
preprocessed, formatted and reported unsolicited 
to the OSS. 

Otherwise, CCITT Recommendation G.821 
performance parameters (including, for example, 
total number of errors, number of error-free sec¬ 
onds, seconds of break, total breaks on a given 
day, number of days with one break) are pro¬ 
cessed, stored within the PCP and passed in re¬ 
sponse to interrogation by the OSS, once every 
24 hours. In addition, TNS provides facilities for 
operators to read performance data for individual 
items of transmission equipment. 

DSMNEs and IONEs, and PCPs are housed in 
a PCE shelf, which incorporates a power supply. 
Each transmission station can comprise one or 
more PCPs, depending on the station size, al¬ 
though most stations can be accommodated by a 
single PCP. 


Communication Infrastructure 

In the main transmission station, each PCE is 
connected by a serial link to a packet assem- 
bler/disassembler (PAD), which acts as a com¬ 
munications concentrator. The PAD converts 
asynchronous V.24 messages from PCEs to X.25 
packet transmission, and reconverts incoming 
messages sent by the OSS. A number of PCEs can 
be connected to a single PAD via RS232 links. 
Local PCEs are connected directly by simple, 
cost-effective line drivers; remote PCEs use a 
modem link or statistical multiplexer. 

X.25 packet transmissions are sent via the 
X.25 administration data packet network 
(ADPN). In the NACC OSS, discs and worksta¬ 
tions are interconnected by an Ethernet local area 
network (LAN). 

In the NOU, TNS users are linked by an ILAN 
(INTERNET LAN or T-NET Plus) network 
which links workstations, VT200 terminals, and 
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Ml779 terminals. Users also require access to the 
transmission network configuration database 
held by the junction network system (JNS) and 
computer-aided maintenance of special services 
(CAMSS). This is provided by dedicated SNA 
gateways in the NACC, and by the ILAN. 

Operations Support System 

The heart of the TNS system is the OSS which 
performs: 

© alarm handling; 

® performance data monitoring; and 

• data collect equipment management. 

The OSS is installed on a VAX 4000 host 
processor in the NACC, and supported by an 
array of high-performance peripherals which in¬ 
clude a pair of shadowed discs (see Figure 2). The 
OSS contains the PCP database, which holds de¬ 
tailed information about the data collection net¬ 
work, equipment being monitored, and alarm and 
performance data being collected. 

OSS alarm handling includes the collection (on 
a secured log) and processing of alarms from sub¬ 
ordinate PCEs. It then presents these alarms to 
users as maintenance tasks. The OSS also performs 
the important function of alarm association. This 
requires that alarms from the same equipment are 
grouped together and presented as a single task, 
stored by the OSS for future reference. 

The OSS presents threshold exceptions and 
performance data which is collected and stored 
for viewing over a selected 24 hour period. 

Finally, the OSS provides functions to man¬ 
age the data collection network. This includes 
facilities to download and validate new, updated 
PCP software, and to perform data-building and 
system administration activities, the latter in¬ 
cluding data collection network configuration 
data, and details of monitored transmission 
equipment. 

NETMON SYSTEM DESCRIPTION 

NETMON has provided BT with a cost-effective 
solution to manage transmission elements in its 
inner core (trunk) network. Communication links 
connecting repeater/radio stations to the NOUs 
enable data from monitored transmission ele¬ 
ments to be centralised at the NOU, and down¬ 
loaded to the national support centre at Milton 
Keynes. The system provides: 

• capability for rapid detection of failures and 
accurate matching of faults to specific equipment; 

• performance monitoring to highlight problems 
which conventional alarm systems and protection 
switching are not designed to report; and 

® real-time event reports. 

NETMON System Architecture 

The system comprises several individual compo¬ 
nents, which (as in TNS) can be categorised into 
data collecting network, communications infra¬ 


structure, and central processing. The central pro¬ 
cessing in NETMON is, however, distributed 
over a number of collocated processors (see 
Figure 3). 

The data collecting network comprises a num¬ 
ber of data collect components, the principal ones 
being station surveillance units located at remote 
transmission sites. Each station surveillance unit 
consists of three main microprocessor-controlled 
elements which can be treated as separate entities. 
These are: 

(a) the digital radio and line scanner (DRLS); 

( b) the alarm logging equipment (ALE); and 

(c) the collator. 

Digital Radio and Line Scanner 

The DRLS monitors error rates, loss of signal, 
loss of alignment and so on, on digital radio and 
line equipment in the inner core (trunk) network. 

Alarm Logging Equipment 

The ALE is a general-purpose alarm interface and 
can transmit any alarm condition based on voltage 
from repeater stations or exchanges. It is also 
possible for a limited set of commands to be 
issued remotely from the NOU in order, for 
example, to effect resets. 

Collator 

This unit acts as an interface between the shared 
peripheral devices (printer, terminal and one or 
two modems), and satellite units. It is used to 
drive a modem link which sends data from the 
data collect equipment via the public switched 
telephone network to a remote NETMON com¬ 
puter at the NOU. 

In addition to the station surveillance units, a 
number of other data collect components are 
used. These include: 

(a) Digital Multiplex Data Logger (DMDL) 
The DMDL is a microprocessor-controlled unit 

capable of detecting on/off events of duration as 
small as 4 ps. It also detects and reports multiple 
muldex frame-alignment alarms from either 2-8, 
8-34, or 34—140 Mbit/s multiplexers, and reports 
alarms when four consecutive incorrect frame- 
alignment signals are received. The DMDL can be 
also deployed to capture ordinary alarms, saving 
the cost of separate ALE/DRLS equipment. 

(b) ASPEIf Monitoring Unit (AMU) 

The AMU is a microprocessor-controlled unit 
designed to interface NETMON to the ASPE units. 
Its main function is to give an indication of switch¬ 
ing activities onto the service protection network, 
and to allow remote switching from the NOU. 

(c) Radio Control Unit(RCU) 

The RCU is the equivalent of the AMU for 
microwave radio transmission equipment. It en¬ 
ables microwave radio channel switched protec¬ 
tion equipment to be controlled and monitored. 


t Automatic switched protection equipment 
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Figure 3 
NETMON 
system 
architecture 


( d) Gateway G 

Some smaller transmission stations are fitted 
with Gateway G monitoring equipment. These 
units transmit one alarm input per system for 
digital line and radio systems, and one alarm 
input for each level of multiplexer for digital 
multiplexer equipment. In many transmission 
stations, Gateway G is used as a standalone 
system. Remote sites are normally linked to a 
central reporting unit, which in turn feeds alarm 
information to a Gateway alarm analyser, part 
of the NETMON computer equipment at the 
NOU. 

Events from each data collect equipment are 
compared in severity with set thresholds. Those 
events below the threshold are stored until the 
central unit in the NOU polls the monitored site. 
Events exceeding these preset thresholds are sent 
immediately to the NETMON central unit as 
alarms which have to be acknowledged by NOU 
operators. Incoming data from each station sur¬ 
veillance unit is diverted to one of a series of 
screens, depending on their origin, and each re¬ 
port can be highlighted in different ways to ident¬ 
ify the type of fault represented. 


NETMON Central Processing 

The main NETMON computer consists of several 
processors linked by an Econet LAN (see 
Figure 3). These processors are briefly described 
in turn. 

File Server 

This server provides disc storage facilities for all 
the other processors in the NETMON network. 

Auto Poller 

This unit interrogates all remote data collect units 
at predetermined intervals to download remote 
unit fault files, synchronise remote sites (every 24 
hours), and conduct confidence checks (every 
two hours). After polling is complete, the autopol¬ 
ler combines all the polled data into an archive 
file on the file server. One file is kept for each 
date, and each file is kept for a maximum of 30 
days before automatic deletion. 

NETBASE PC 

Once the remote data files have been gathered, a 
PC-based analysis package, NETBASE, pro- 
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cesses and prints a league table of system perfor¬ 
mance over a preset number of previous days 
(usually 30). The league tables enable faults, 
failures, and trends to be analysed. This analysis, 
called black-spot/gold-spot analysis , has proven 
to be very useful in identifying and fixing trouble¬ 
some circuits, or highlighting reliable circuits. 

Link Processor 

This unit provides communication between cen¬ 
tral sites (NOUs), and the National Support Site 
at Milton Keynes which monitors alarm and per¬ 
formance statistics nationally. The link processor 
uses a modem to communicate over the trunk 
administration network (TAN). 

Report and Status , Switch Processor and 
Alarm Processor Units 

In conjunction with directly attached VDUs, 
these units provide immediate views of perfor¬ 
mance information reported by DRLS/DMDL, 
AMU/RCU, and ALE/Gateway data collect 
equipment, respectively. Alarm information is 
presented to operators through various display 
screens on VDUs. Operators can use custom key¬ 
pads to switch rapidly between a number of 
screens displaying alarm information in a number 
of pre-defined formats. 

Gateway Alarm Analyser 

This unit collects data from Gateway central re¬ 
porting units located at remote transmission sites. 
It converts the alarms received into a format rec¬ 
ognised by NETMON and presents alarm details 
on the alarm processor VDU, together with 
alarms from the ALE unit. 

Operator Terminals 

These are actually Acorn Master (BBC) series 
computers with which operators can gain access 
to NETMON system facilities. 

IMPLEMENTATION PLANS 

NETMON has already been extensively deployed 
throughout the inner core (trunk) network. In 
addition, several sites in the outer core (junction) 
network have a significant penetration of higher- 
order systems collocated with inner core (trunk) 
network plant. These outer core (junction) net¬ 
work systems are normally connected to NET¬ 
MON, if there is sufficient spare capacity. 
Currently, NETMON monitors network elements 
at about 600 sites throughout the UK, out of a total 
of 5000. These elements comprise approximately 
67 000 alarm inputs, with each NOU gathering on 
average, 9000 events per day. 

While the deployment of NETMON is exten¬ 
sive and at a mature stage, TNS deployment is in 
contrast embryonic, with just under 50 trans¬ 
mission stations being monitored country-wide, 
at present. Full implementation of TNS requires 
a major investment of resources, and the 


coordination of activities across a wide spectrum 
of disciplines to install both the computer hard¬ 
ware with configured TNS application software, 
and the data collect equipment required to collect 
surveillance data. 

Thus, in order to maximise the effectiveness of 
the implementation programme, TNS deploy¬ 
ment has to be prioritised. Currently, this priority 
is aimed at delivering the maximum quality of 
service improvements for digital private cir- 
cuits/Premium Services. 

TNS computer hardware with configured TNS 
application software has now completed field and 
product trial stages in London. TNS hardware and 
TNS Release 0.1 application software are now 
installed in NACCs at Croydon, Manchester, 
Wolverhampton, Bristol and Leeds. Also, a spe¬ 
cial release of TNS, TNS0.1E, enhanced to meet 
the requirements of international transmission 
operations, has been installed at Madley. 

The dates for initial TNS hardware and appli¬ 
cation software deployment to the remaining 
NOU catchment areas are: 

Southern Home Counties Oct. 1991 

Northern Home Counties Jan. 1992 

Scotland Apr. 1992 

Northern Ireland Jul. 1992 

With regard to the TNS data collect equip¬ 
ment, the deployment strategy for retrofit is that: 

© TNS is being used to monitor larger trans¬ 
mission nodes where no surveillance exists, or 
where existing NETMON capacity is near full 
utilisation; 

@ utilisation of spare NETMON capacity, if suf¬ 
ficient, is considered for deployment at co-sited 
transmission nodes; 

© TNS, where installed, will be fully deployed at 
8 Mbit/s and above. TNS deployment at 2 Mbit/s, 
is being focused at services such as MegaStream; 
and 

O in small transmission nodes such as small local 
exchanges, existing surveillance methods includ¬ 
ing Gateway, REAMS and so on, will continue to 
be used, for a period of time. 

This strategy aims, initially, to focus deploy¬ 
ment of the TNS data collect equipment and net¬ 
work interface units on the outer core (junction) 
network sites. Inner core (trunk) network stations, 
the majority of which are already monitored by 
NETMON, will be delayed until the end of the 
initial roll-out programme in the latter half of the 
1990s. This plan gives maximum surveillance 
coverage, and leads to a quicker realisation of the 
benefits envisaged from the surveillance pro¬ 
gramme. 

Even so, the implementation programme is 
very ambitious, and while TNS station surveill¬ 
ance is still rather modest (see Figure 4), this will 
change rapidly in the next few months. For 
example, in London, surveillance is planned for 
76 sites during 1991-92, with the ultimate capac¬ 
ity in London of the order of 300 sites, serving 
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Figure 4 
TNS station 
monitoring 4 year 
implementation 
plan 


Figure 5 
TNS 4 year 
station coverage 
plan 


400 000 transmission systems. This capacity is an 
order of magnitude greater than current NET- 
MON deployment in London. 

Figure 5 shows the approximate number of 
national transmission sites that are planned for 
surveillance for the first four years of the six year 
programme, together with the approximate per¬ 
centage of transmission station coverage that 
these figures represent. 

THE NEXT STEPS 

TNS and NETMON are converging into an inte¬ 
grated, consistent system which incorporates and 
builds upon the best features of both systems. The 
drive behind this integration of surveillance sys¬ 
tems within the transmission domain is based on 
the need to provide tools to aid the operational 
processes which guide the flow-through of events 


TRANSMISSION SITES 

NUMBER PERCENTAGE 
COVERED 



from their occurrence, through reception, diag¬ 
nosis and ultimate repair. 

TNS priority development steps are: 

© enhancement of existing TNS0.1 user inter¬ 
face and adoption of a network management 
workstation (NMW2); 

® the introduction of basic correlation functions; 
© real-time display of alarms; 

® interface to the work management system; and 
© performance management functions. 

One of the key development targets due for 
trial in February 1992 is the enhanced user inter¬ 
face which is better geared to the needs of the 
NOU transmission operations and maintenance 
staff. Such an interface will be realised by the 
UNIX-based NMW2 platform which will cut 
down on the number of terminals required, giving 
NOU users multiple access to TNS, NETMON, 
and other TNS support systems from the same 
workstation in a consistent fashion. This interface 
will be based on generic fault management soft¬ 
ware with added TNS functionality. It will also 
use the common management information ser¬ 
vice (CMIS) Cooperative Networking Architec¬ 
ture-Management (CNA-M) conformant 
communications stack for interoperability with 
the main body of TNS software. 

This transmission management application 
software will incorporate temporal correlation 
(that is, correlation based on the time interval 
between alarms) to group associated alarms re¬ 
ceived from both TNS and NETMON, enabling 
users to identify the underlying problems more 
swiftly. In this configuration, the transmission 
application will act as the manager node, sending 
commands to TNS (the agent node) to control 
sieves in TNS event management software. The 
user will therefore be able to select what type of 
events are to be transmitted from the main TNS 
system, ensuring that the user at the transmission 
workstation is not overwhelmed with inconse¬ 
quential events. 

The correlation will further help to filter much 
of the alarm information that would otherwise be 
displayed to the user at the transmission manage¬ 
ment workstation. Thus, while the initial im¬ 
plementation of transmission event correlation 
concentrates on temporal correlation in the work¬ 
station domain, it is expected that some correla¬ 
tion functionality will eventually have to migrate 
down closer to the event collection equipment. 

Real-time display of alarms will be available 
in the next release of TNS. This feature requires 
a separate display and terminal, and will contin¬ 
ually show the status of events. It is intended to 
give a continuous update overview of event status 
without the need to perform repeated terminal 
actions. This will enable a better integration of 
TNS into the NOU environment, and remove the 
need for the simple interface linking TNS to the 
NOMS1 system. 

Worldwide Network’s work management sys¬ 
tem is NOMS2, which will be evolved into the 
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WMS Module 1 for networks. WMS will interface 
to TNS for information via a CNA-M interface 
such as CMIS. 

Performance management functions similar to 
that now available on NETMON using NET- 
BASE PC will be made available to TNS users. 
This will allow users to generate league tables for 
black-spot/gold-spot analysis. 

In order to maximise the surveillance coverage 
across the network in the most cost-effective 
manner, it is necessary to incorporate the existing 
NETMON event collection infrastructure, and 
hence NETMON is also on an evolutionary path 
towards integration across the transmission do¬ 
main. Its priority development steps are: 

(a) porting NETMON central functionality to 
a UNIX platform; 

( b ) provision of an enhanced user interface 
using NMW2; 

(c) CMIS interface for interworking with the 
transmission management workstation; 

(d) CMIS interface for interworking with 
TNS; and 

(e) interworking with the RS485 surveillance 
interface. 

Owing to the diminishing external support for 
Acom Master (BBC) series computers, it is in¬ 
tended to port NETMON’s central functionality 
onto a UNIX platform. This plan is linked with 
the provision of the UNIX-based NMW2 envi¬ 
ronment which would achieve top-level integra¬ 
tion with a common NETMON/TNS application. 
The NMW2 windowing environment will be de¬ 
veloped along with the transmission management 
application to achieve a common ‘look and feel’ 
for both systems. 

This UNIX implementation will be followed 
by the provision of a CMIS interface which will 
allow NETMON to inter-work with TNS. 

NETMON was deployed before the definition 
of the RC8245-RS485 standard surveillance in¬ 
terface, and is currently unable to interoperate 
with these interfaces. Over the last few years, the 
rapid expansion of the transmission network and 
the introduction of new transmission equipment, 
all fitted with the standard interface, has led to an 
increasing number of transmission elements not 
being monitored. To rectify this, it is now in¬ 
tended to develop a cost-effective unit between 
the standard RS485 surveillance interface and 
NETMON satellite units, enabling NETMON 
surveillance of new transmission kit, where this 
is cost effective. 

FUTURE 

The TNS will provide the long-term architecture 
for transmission management, into which NET¬ 
MON and other interim systems will fit. In the 
case of NETMON, this will be achieved by mod¬ 
ifying the unit between the RS485 interface and 
NETMON satellite units to enable the latter to act 
as NSIUs. This will allow NETMON to share the 
same communications infrastructure as TNS, and 


utilise common OSS facilities such as the secured 
(high level) log. This integrated view goes hand 
in hand with plans to rationalise the communica¬ 
tions infrastructure, reducing further operation 
and maintenance costs. 

In the development of TNS, incorporation of 
generic software such as component fault man¬ 
agement software will be a high priority. In addi¬ 
tion, significant care will be taken to make 
maximum use of functionality already developed. 
This is especially true for the data collect equip¬ 
ment already deployed and which will remain 
compatible as TNS evolves. 

The architecture for full integration across the 
transmission domain is now being finalised. 
When completed later this year, it will provide the 
focus for later development releases. There will 
be two more major releases (TNS0.2 and TNS0.3) 
before the final release, TNS 1.0, in the second 
quarter of 1993. This will complete the current 
development programme. 

It is clear, however, that a view is required 
beyond the integration of TNS and NETMON 
encompassing the wider range of systems provid¬ 
ing transmission information. Such a view (see 
Figure 6) requires the interoperability of a number 
of systems, with a correlation /grouping function 
based on that to be provided by the transmission 
management application. 

The scope of integration is wide ranging, in¬ 
cluding issues such as: 

© the introduction of the synchronous digital 
hierarchy, and the need for a common approach 
to both the synchronous digital hierarchy and 
plesiochronous digital hierarchy; 

© driving down the cost of ownership by the use 
of a shared communications infrastructure be¬ 
tween systems, for example, transmission, power 
and building environment alarm systems; 

© fallback/disaster recovery facilities; 

© test management; 

© making transmission network element inter¬ 
faces accessible via international standards such 


Figure 6 
Possible future 
interworking of 
transmission 
domain systems 
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as CMIS, SNMP and CCITT Q.2 Recommenda¬ 
tions in the data collect equipment environment; 
and 

© end-to-end (customer premises) management 
and integration with access management systems. 

In the long run, it is intended to have this 
correlation performed virtually in ‘real time’. To 
this end, development of other types of correla¬ 
tion techniques will be undertaken to supplement 
the original correlation methods. 

CONCLUSIONS 

The thrust of the TNS programme can be broken 
down into two parallel activities: the first is a 
concentrated deployment of monitoring infra¬ 
structure to maximise surveillance coverage; the 
second is a focus on phased development of the 
system to provide incremental functionality 
changes in line with operational needs. 

The TNS and NETMON programmes are both 
key elements of the NAIP. The evolution plans for 
these two programmes converge towards a uni¬ 
fied network surveillance capability for BT, 
bringing a rationalisation and reduction in oper¬ 
ation and maintenance costs. The precise archi¬ 
tecture to achieve full integration is close to being 
finalised. 

The single most daunting challenge, however, 
is simply the sheer size and cost of the total 
surveillance programme. For example, over 5000 
locations (consisting of up to 400 000 systems) 
will eventually be monitored and supported by a 
single OSS node. In addition, the context of TNS 
within the FARMS! study has been, and will be, 
a major consideration. The road ahead is therefore 
a challenging one. 

Completion of the final release of the current 
TNS program (TNS 1.0, due in the second quarter 
of 1993) will deliver comprehensive transmission 
surveillance capability across the transmission 
domain. 
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Work Management System 

G. J. GARWOODt, and A. C. ROBINSON* * 


As a result of a study to initiate major improvements to the work management activity, a work 
management system was identified as a key area of development. This article outlines the development 
of a real-time process control system required to provide such a work management system. 


INTRODUCTION 

What is Work Management 

At any given time, the company will require work 
to be undertaken. It will also have available people 
who are able to perform that work. The task of work 
management is to match the available people to the 
required work in an optimal manner. 

Work Management Programme 

The Work Management Programme (WMP) was 
formed, in 1988, to initiate major improvements to 
work management activity. The requirement was 
to study the current situation, to propose a future 
strategy, to plan a course of action, to understand 
the benefits and costs, to develop any systems that 
may be required, together with changes in oper¬ 
ational procedures and then implement. 

The WMP had to take into account other key 
BT initiatives, in particular the Network Admin¬ 
istration Implementation Programme (NAIP) 1 , 
and the Strategic Systems Plan (SSP) 2 . 

In the light of the above initiatives, the WMP 
undertook a detailed analysis of business costs 
and failures, including the manpower utilisation 
surveys which clearly pin-pointed areas for im¬ 
provement. At the same time, increasing pressure 
on the business in the form of competition, fo¬ 
cused the vision on improving the quality of cus¬ 
tomer services and reducing unit operating costs. 

WMP Objectives 

The main objectives can be crystallised in the 
following form: 

• to get the right person 

• in the right place 

• at the right time 

• with the right stores 

• and the right information 

and provide information so that we know 

• where the person is 

• what he/she is doing 

• when he/she will finish 

• what he/she will do next. 
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WMP Deliverables 

After intensive and extensive analysis, the WMP 
charted a migration and implementation plan fo¬ 
cusing on three key areas: 

(a) what initiatives currently existed which 
could be coordinated and enhanced, 

0 b ) what new initiatives would make the real 
step improvements which could only be achieved 
by a major change programme, and 

(c) what facilities and functionality would 
give early benefits and would support a strong 
business case. 

For (a), a local initiative on time recording, to 
use a Psion Organiser for replacing paper-based job 
allocation sheets and improving management in¬ 
formation, would be rolled out together with en¬ 
hancements to the Customer Service System 
(CSS) 3 , to support the activity. These projects are 
now known as Cipher and National Job Recording. 

For (b) and (c), a new development would be 
undertaken, with the working name of WMP 
Module 7, which would offer: 

• electronic communication of work details and 
work progress between field technicians and cen¬ 
tral systems, 

# significant improvements to the decision pro¬ 
cess with regard to resource allocation and con¬ 
trol, 

# facilitation of multi-skill working covering 
both repair and installation, and 

• an available developed system which could 
commence pilot trial in 1991. 

This article concentrates on the work manage¬ 
ment system (WMS), the central deliverable of 
Module 1. 

OPERATIONAL REQUIREMENTS AND 
USE 

Under the leadership of the WMP, people con¬ 
cerned with future operational requirements met 
with BT Development and Procurement in late- 
1989 and January 1990 to consider how the state¬ 
ment of user requirements could be translated into 
computer systems that could be realised within 
the challenging delivery time-scale. A key objec¬ 
tive was to build upon existing support systems 
and reuse functionality wherever feasible. 
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Figure 1 
Technical 
solution for 
WMP Module 1 


The process inevitably led to some com¬ 
promise between the requirements and the 
achievable technical solution. Some require¬ 
ments were scoped out (to form part of later 
deliverables), while modification/enhancements 
to existing systems were identified together with 
new developments. The main criterion in making 
the decisions was to achieve maximum oper¬ 
ational benefit within the required time-scales. 

Operational Scope 

A statement of requirements (SOR) was then pro¬ 
duced which formed the framework within which 
the project has operated. 

The main focus covered the allocation and 
control of work. Table 1 identifies the specific 
work areas. 

After the reorganisation of BT under Project 
Sovereign, the above were aligned with the re¬ 
spective parts of Personal Communication Divi¬ 
sion (PCD), Business Communication Division 
(BCD) and Worldwide Networks (WN). 

Technical Scope 

The proposed technical solution for Module 1 
takes full advantage of existing systems and the 
functionality they offer, combined with new de¬ 
velopments, as illustrated in Figure 1 showing 
both the customer and the network aspects. 

WMS will be connected, via a new interface, 
to the CSS which can provide details of orders and 
repairs, customer information, appointments or 
target clear response times, people information 
and product skill identification. 



Table 1 

Original SOR Scope 


PSTN Repair 

Customer Apparatus and Line 
Faultsmen / Jointers 

Renters and Public Payphones 
Job and Pay Records 

PSTN Installation 

Single Line Residential 
and Business 

Renters Payphone 

Job and Pay Records 

Network Operations Repair for TXD 

Repair for TXE4 

Repair for Transmission 
Buildings and Power 


The WMS will take account of contractual 
agreements in terms of response time, the size of 
the job, and the skill required with the availability 
and location of the field technicians who possess 
the requisite skills. Further, it will take account of 
existing work, recognising that each item of work 
will take different amounts of time and will be 
undertaken at different locations. Sophisticated 
algorithms will match the required work with the 
people available in the most efficient manner. 

The WMS development, based on the existing 
network operations management system 
(NOMS2) 4 , is to be made available as two vari¬ 
ants, WMS(C) for customer-facing activities, and 
WMS(N) for network operations. Both will have 
a substantial common core element. 

For the WMS(C) option, work will be des¬ 
patched to field technicians via a field access inter¬ 
face system (FAIS) to hand-held field terminals. 

Operational Benefit 

The main benefit to be derived from WMS is the 
opportunity to improve productivity whilst main¬ 
taining service levels to the customer and reduc¬ 
ing failures. Specific gains will be by: 

$ optimum allocation of a day’s work over a 
large geographical area, 

• taking full advantage of multi-skilling oppor¬ 
tunities, 

• automation of routine control and allocation 
processes, 

• provision of a multi-stage jeopardy system 
enabling improved management of potential 
failure situations, 

• more visibility of work progress, 

• reduction in ineffective time and wasted time 
(travel time per job, waiting to contact control 
etc.), 

• provision of full job information plus previous 
fault history to field technicians, and 

• significant reduction in paperwork and recon¬ 
ciliation procedures by electronic collection of 
time, jobs, and activity data just once, for all 
operational, accounting and pay purposes. 
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It is expected that customers will benefit 
through reduction in failures, better appointment 
keeping and improved flexibility. Ultimately, the 
reduction in operational unit costs will provide 
BT with the opportunity to perform work often 
not done (for example, uplift), and to reduce 
service costs to the customer. 

STRATEGIC REQUIREMENTS 
Strategic Process 

The SSP identified how the company should 
operate. It established ‘manage people and work’ 
as one of the five key high-level processes, which 
with others, in particular ‘serve the customer’ and 
‘run the network’, is present in most of the end- 
to-end business processes or workstrings. This 
vital area should be standardised and wherever 
possible automated to allow all other processes to 
use the same approach. 

The WMP started at the outset to map its work 
on to this process, thus achieving a single devel¬ 
opment and maximising its use for the company. 

Strategic Technology 

Major companies are now moving their computer 
technology towards ‘open computing platforms’, 
in order to gain commercial advantage through 
competitive tendering and selectively choosing 
appropriate technology. 

The WMS product is required to be capable of 
being ported to a range of computer systems and 
thus be conformant to the ‘open platform’ concepts. 

Strategic Business 

The WMS is required to support the work man¬ 
agement requirements of PCD, BCD and WN. 
Ideally it should be capable of supporting all other 
work management functions within the company. 

A strategic requirement is that the majority of 
the software should be reusable. This allows 
WMS to be tailored to many applications through 
small specific enhancements to a common 
generic base and hence benefit from lower devel¬ 
opment costs. 

WORK MANAGEMENT SYSTEM 
System Overview 

WMS is a real-time process control system which 
is required to automate the process of matching the 
required work to the available field technicians 
who are able to undertake that work. It has to 
undertake this task as a continuous process, con¬ 
stantly optimising its allocation as real-time events 
occur. It must support both customer facing and 
network operations for both installation and repair 
activities. Two variants of Module 1 have been 
produced from a common development pro¬ 
gramme; WMS(C) for customer-facing activities, 
and WMS(N) for network operations, each sharing 
a substantial core element. Figures 2(a) and 2(b) 


identify the major components for both variants 
and show the common elements. 

WMS(C) Facilities 

In the customer-facing domain, CSS maintains a 
file of jobs to be undertaken, field technician 
attributes such as addresses, telephone numbers 
and training, together with associated standards 
covering the equipment involved, job completion 
times, and skills required. WMS(C) receives this 
information through a CSS interface, and uses it 
to identify future or ‘same day’ work. The primary 
goal is to assign the right field technician who will 
incur the minimum cost to the business while 
meeting quality-of-service targets and customer 
commitments. 

In a typical eight hour day, each WMS(C) will 
handle up to 10 000 jobs with up to 1200 field management 
technicians. system 


JOB 

COMPLETION 


JOB DETAILS 


RESOURCE 

DETAILS 

UPDATES 

PAY DATA 


JOB RECORDING 
STATUS 
INFORMATION 


RESOURCE MANAGERS 



ALLOCATED 


JOB DETAILS 
JOB 

COMPLETION 


AND PAY 
DETAILS 


* COMMON TO WMS(N) 


(a) Customer facing WMS(C) 


JOB INPUT 


JOB 

COMPLETION 


JOB DETAILS 

RESOURCE 

DETAILS 

UPDATES 


JOB STATUS 

◄- 


EXCHANGE 

ALARMS 


N0U RESOURCE MANAGERS 



JOB DETAILS 


JOB 

COMPLETION 


CALL FIELD 
TECHNICIAN 


* Common to WMS(C) 


(b) Network operations WMS(N) 
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Planned Work 

Customer work which can be planned in advance 
generally consists of installation or routine work. 
In response to orders placed via CSS, including 
those with appointments, WMS(C) compiles a list 
of consecutive jobs, known as a TOUR , for a 
single day for each technician. 

In building the TOUR, WMS(C) takes into 
account the following field technician at¬ 
tributes: locations and stores point, start and 
finish times, any planned absences, overtime 
availability, skills, and preference for type of 
work. These are then balanced against the job 
attributes: the location, estimated duration, skill 
required and appointment time. The primary 
goal is to fill completely the working day with 
minimum ineffective time, including travelling 
time. This process involves a two-stage ap¬ 
proach. 

An initial build can take place up to three days 
in advance of appointment date. Work is balanced 
between geographic areas, and jobs which may be 
done by the same field technician. In addition, the 
starting and/or stores point is identified and stores 
ordered. 

On the night before, the final build takes place 
in which the jobs are allocated to the actual field 
technician. The build takes into account any 
amendments received since the initial build, pre¬ 
assigned jobs, any concentration of work, travel¬ 
ling time and any slack time. 

It is also possible to plan non-CSS work, for 
example, uplift and rewiring, into TOURs by 
direct input into WMS(C). 

Unplanned Work 

Since faults arrive as unsolicited reports, repairs 
cannot be planned in advanced. Further, as each 
repair job will have its own priority, the preferred 
sequence of attending to such work will contin¬ 
ually change. 

To handle this, WMS(C) is equipped with a 
real-time algorithm which runs every few 
minutes to refresh the allocation of unassigned 
work. This takes into account not only those at¬ 
tributes given for the TOUR build work but, in 
addition, the priority of each job (based on cus¬ 
tomer class of service and remaining time before 
jeopardy), those field technicians who are likely 
to become available shortly, and local geography. 
If planned work cannot be undertaken owing to 
unforeseen events (for example, work taking 
longer than expected or field technicians sud¬ 
denly being unavailable), it can be removed from 
the TOUR and handled by the real-time algo¬ 
rithm. 

Despatch 

Each field technician will be equipped with a 
hand-held field terminal, a small computer in its 
own right, with which they can communicate with 
WMS(C). The interface between these terminals 
and WMS(C) is via FAIS, which manages the 


access rights, security, line protocols and the data 
exchange. 

To communicate with WMS(C), the field tech¬ 
nician plugs his terminal into a standard telephone 
line and calls a pre-allocated telephone number. 
Once the link is established, via FAIS, the techni¬ 
cian can obtain full details of the next job. Further, 
on completion of the work, he can communicate 
to WMS(C) job closure information or progress 
to date. 

To complete the work cycle, WMS(C) pro¬ 
vides a store-and-forward function to update the 
job and pay recording module via the CSS na¬ 
tional job recording module. 


WMS(N) Facilities 

In the network situation, WMS(N) supports cor¬ 
rective and preventative maintenance. In the in¬ 
itial version, alarm and current information from 
digital and electronic exchanges and transmission 
systems will be transferred electronically from 
the alarm collection system known as the Network 
Operations and Maintenance System 1 
(NOMS1). Information on customer-reported 
network-related faults will be transferred via the 
CSS-WMS link. 

Most other WMS(N) facilities have been 
derived from the design of WMS(C) together with 
the main features of NOMS2. Most of the time 
and skill standards are created automatically 
within WMS(N) and the facility to input work 
manually allows other activities to be managed by 
the system. WMS(N) also has the ability to sche¬ 
dule automatically routine maintenance acti¬ 
vities. 

Since WMS(N) is only concerned with the 
real-time allocation of work, the TOUR build 
function has not been provided. Communication 
to the field technicians will, at present, be via the 
existing fixed terminal network rather than using 
the portable field terminal. 

Further, as network operations differ from the 
customer-facing requirements, a number of the 
user screens have been modified to meet the spe¬ 
cific network need. 

Nevertheless, even with different features, 
some 70% of the total software is common to 
WMS(C) and WMS(N) and constitutes a core 
element. 

User Interface for both WMS(C) and 
WMS(N) 

WMS has been equipped with a range of user 
tools to allow operational users to tailor WMS to 
their operational needs. By using an executive 
tool known as the session controller, a whole 
range of specialised facilities, known as transac¬ 
tions , allow people at the centre to enter informa¬ 
tion, and monitor the flow of work. 

WMS offers a user-friendly interface which 
conforms to the CNA-M style guide, making use 
of drop-down menus, forms and picklists. These 
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are typically overlaid on each other during trans¬ 
actions allowing continuous progression through 
a transaction. For experienced users, options exist 
to execute a series of complex tasks by entering 
brief instructions on a command line. 

The data-build tool allows the user to create, 
modify and delete fundamental information in the 
database; for example, allocation parameters, 
work types, people details, domain controls and 
constraints, exchange areas, and travel time par¬ 
ameters. 

Several standard tools have been provided to 
allow the resource managers to progress and 
monitor the flow of work. These provide them 
with visibility of jobs pending and in progress, 
TOUR details per technician, resources available 
and work/staff jeopardy situations. Jeopardy 
monitoring in real-time provides a continuous 
picture of the total work situation. 

Development 

The WMS system architecture and detailed de¬ 
sign took into account the following aspects: 

Development Environment 

A network of workstations and computer sys¬ 
tems was engineered such that the developed 
system could be ported to a range of target 
machines. 

Technology Standards 

In supporting the open approach, the implemen¬ 
tation was undertaken using the software lan¬ 
guages C and C ++ (featuring object-oriented 
design), under the UNIX operating system V and 
employing the ORACLE relational database 
management system. These tools have a very 
large user base and thus provide additional bene¬ 
fits in terms of facilities and support. 

The benefits of symmetrical multi-processing 
have been exploited by using a number of concur¬ 
rent processes. In addition, certain processes are 
also configured as client/server models, with 
remote procedure calls being used for communi¬ 
cations. 

For inter-computer communication (WMS- 
CSS and WMS-FAIS), the de-facto standard 
TCP/IP protocols have been adopted. This 
allowed readily available interface units to be 
purchased, enabling a UNIX environment to 
communicate with an MVS environment. 

Reusable Features 

Using the experience of developing NOMS2, it 
was possible to produce a design for WMS with 
many reusable features. The combination of this 
approach with those above has resulted in a 
generic solution. 

Software Methods and Tools 

Software engineering tools (the Yourdon software 
methodology support by the Software through 


Pictures (StP tool) were successfully used to pro¬ 
duce a singular but comprehensive design, cap¬ 
tured in electronic form. All objects and their 
relationships are checked to be logically correct 
while missing ones are noted. 

StP provides total visibility of the design, mak¬ 
ing it easier to understand and change when re¬ 
quired. 

On completion of the design, WMP people 
were then involved in the review process to en¬ 
sure all parties achieved a mutual understanding 
of precisely what is required and what is to be 
developed. This approach is to be recommended 
to all developments. 

System Build, Integration, Test and 
Release 

For WMS, separate units were charged with sys¬ 
tem build and integration, testing and release 
phases, independent from the development stage. 

System Build and Integration 

This is the process of incrementally building the 
system until all the code units have been inte¬ 
grated and the complete system can be run on the 
target platform. 

System Validation, Verification and Test 

Traditionally this has been a manual task. How¬ 
ever, for WMS, approximately 70% of the re¬ 
quired component, system and regression testing 
was automated. 

By using suitable test tools, a range of test 
scripts was developed to provide the automatic 
test environment, covering execution, documen¬ 
tation, test results, metrics and traceability ana¬ 
lysis. A typical test suite which used to take three 
days to administer, and was error prone, is now 
undertaken in 40 minutes. Further, the tests were 
executed repeatedly and consistently, with or 
without user intervention. 

Automatic testing has not only improved pro¬ 
ductivity and quality, but has made testing into an 
interesting and challenging activity. 

Release 

A separate unit provides the installation and com¬ 
missioning of the system on the target machine on 
site, provides product familiarisation with the 
field users, and subsequent support of the system. 

In summary, the acceptance cycle (system 
build to release), for builds of WMS was realised 
in a 7 week period. The integrated approach be¬ 
tween the development and the system test teams, 
together with the use of automatic testing tools 
and techniques made this possible. 

WMP Module 1 System Integration and 
Customer Acceptance Testing 

Once the discrete systems, WMS, CSS, FAIS, and 
field terminal have been released, a process of 
integration, system integration testing and cus- 
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tomer acceptance testing needs to take place. This 
is a complex task which needs to ensure that the 
systems are fully compatible with real data being 
sent across the interfaces. 

To ensure that all systems work together and 
deliver the requirements, initially a period of 6 
months has been allowed. 

IMPLEMENTATION 

Following acceptance of a detailed business case, 
approval was given to undertake a pilot trial to 
demonstrate that the benefits were achievable. 

The trial allowed for both WMS(C and N) to 
be piloted. The location chosen is the old East 
Midlands District which is now part of PCD Mid¬ 
lands, BCD Midlands Wales and West and WN 
Southern. 

The Module 1 deliverable is not just a com¬ 
puter system, but involves developing new oper¬ 
ational processes, procedures and working 
practices which will have a significant impact on 
the company’s field operations. 

The most noticeable change will occur in cus¬ 
tomer-facing operational units where the focus is 
on the automation of the existing process to mini¬ 
mise the need for manual allocation of work. 
People will have new roles of monitoring WMS, 
modifying and changing information about jobs, 
technicians or customers and taking vital deci¬ 
sions on resources and handling work which may 
move into jeopardy. 

Field technicians will have their work des¬ 
patched to them automatically. This provides the 
opportunity to improve their efficiency and effec¬ 
tiveness, and increase job satisfaction by being 
able to do a better job, whilst the field terminal 
will eliminate the paper-work associated with job 
and pay recording activities. 

Field managers will be able to spend more time 
with their people, providing a greater technical 
input as WMS takes over many resource, pay and 
job-related clerical activities. 

Key elements in implementing these changes 
are: 

© that all concerned understand the functionality 
that WMS offers and the potential benefits that 
can be obtained, 

© a full and active involvement of local field 
managers, 

• an understanding of the operational impact, in 
particular the people issues, 

® the provision of the communications infra¬ 
structure, and 

@ the provision of a comprehensive training 
package. 

A WMP team, in close consultation with local 
managers, has developed an implementation plan 
which details all the activities necessary to sup¬ 
port the ‘go-live’ operation. 

On the network side, the situation is slightly 
different, since NOMS2 has already been used to 
manage work allocation and control. Here the key 
implementation issue is how the field migrates 


from NOMS2 to WMS(N). A separate implemen¬ 
tation plan has been developed, but the principles 
given above still apply. 

The project must provide evidence of a suc¬ 
cessful implementation in order to gain auth¬ 
ority to proceed with national roll-out. 
Consequently, the WMP has developed a benefit 
measurement programme which identifies key 
measures to be tracked for a period in advance 
of go-live and then for a further period after 
go-live. These measures, which will cover the 
performance of various operational activities, 
will provide the evidence of impact that WMS 
has had on the business. 

PROJECT MANAGEMENT 

The WMP Module 1 is a large and complex 
project, bringing together many parts of BT with 
different roles and responsibilities. Key to its 
success is sound project management based on 
the structure in Figure 3. 



CAT: Customer acceptance testing 
CSS: Customer Service System 
FAIS: Field access interface system 
SIT: System integration testing 
WMS: Work management system 

Figure 3—Project management structure 


This enabled the coordination of the lead 
WMP team in Manchester with the development 
units from Development and Procurement, lo¬ 
cated in Cardiff, London, Martlesham Heath and 
Ipswich. 


FUTURE OPPORTUNITIES 

The WMS development has made a major step in 
providing the company with a generic solution 
rather than a specific one for a specific applica¬ 
tion. The future opportunities for applying work 
management are now very substantial since the 
means to achieve cost-effective solutions are now 
available. 

Following a successful pilot trial, the scope 
of WMS can be widened, in progressive mo¬ 
dules, to incorporate other PCD, BCD and WN 
requirements, until all appropriate workforces 
within these units are covered. The scope, for 
example, could cover private circuits, multi-line 
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business provision and capital network installa¬ 
tion work. 

In the near future, a generic interface could be 
developed to link WMS to existing support sys¬ 
tems such as operations and maintenance centres 
and transmission network surveillance which 
would significantly improve work flow-through. 

In addition, there is the scope to enhance busi¬ 
ness operations by interconnection with other 
support systems such as stores management, per¬ 
sonnel and finance systems, and private network 
management systems. The added value is auto¬ 
matic work flow-through removing the need for 
paper transactions and human intervention. 

WMS could also be applied to other parts of 
the company, such as Product and Services Man¬ 
agement, Special Businesses and Group HQ. 

CONCLUSION 

The work management programme, through its 
development of WMS, has delivered a key 
strategic system which maps on to a key strategic 
process. Not only will WMP Module 1 generate 
significant benefits in its own right, but it will 
provide a generic base for a much larger applica¬ 
tion of work management across the company. 
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Local Access Network Management 

K. J..MAYNARD, and P. J. HAWLEYt 


The different technologies which are found in or planned for the local access network are considered, 
together with the demands they make upon management systems. The impact of more sophisticated 
customer expectations on the network operator is discussed briefly. Finally, current work on an 
architectural model for the local access network is outlined. 


INTRODUCTION 

The local access network can be considered as the 
first or final hop in the transmission network 
through which all network-operator-supplied ser¬ 
vices pass. Most of these services pass through the 
local access network twice, once for each end 
connection. Only recorded information and en¬ 
quiry services have a single pass through this net¬ 
work. For the purposes of this article, the local 
access network is regarded as starting at the trans¬ 
mission terminating equipment in the serving local 
exchange and ending at the network termination 
equipment (NTE) at the customer’s premises. De¬ 
pending on the technology in question, the trans¬ 
mission terminating equipment may be the main 
distribution frame (MDF), digital distribution 
frame (DDF) or multiplexing equipment. 

At present, BT’s local access network consists, 
in the main, of twisted copper pairs. However, 
other media are also in use, such as optical fibre, 
coaxial cable and radio. A range of network topo¬ 
logies is also in use: star, tree and ring. If the NTE 
in the customer’s premises is also included as part 
of the local access network, then the overall tech¬ 
nology used becomes an important aspect. For 
instance, twisted copper pair can be used to de¬ 
liver simple analogue speech or digital signals up 
to (and in the near future beyond) 400 kbit/s. 
These technologies, in turn, are used to create and 
deliver the many services that BT supplies to its 
customers. 

In order to increase the bandwidth and flexi¬ 
bility for customer service delivery, ever more 
complex technology is being developed. The 
large investment needed to develop this is inevit¬ 
ably concentrating the source of such technology 
in a small number of very large multinational 
companies. This means that all network operators 
in future could potentially have the same range of 
technology with which to deliver customer ser¬ 
vices. It is therefore the efficiency with which 
network operators manage the technology resour¬ 
ces available to them that will distinguish them. 
The technology itself will be a secondary issue in 
gaining profitability. Market share will be deter¬ 
mined by an operator giving customer satisfac¬ 
tion and value for money. 
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Technology variants have been evolving, and 
are continuing to evolve, and are providing net¬ 
work planners with a diversity of solutions for any 
one customer application. These local access net¬ 
work technology variants can be regarded as an 
expanding portfolio of piece parts. It is these piece 
parts that BT as a service provider and network 
operator must use and manage in order to meet 
customer requirements efficiently, flexibly and 
economically. 

TECHNOLOGY VARIANTS 

When discussing the management of the local 
access network, it is useful to establish what some 
of the technologies used are, and what manage¬ 
ment opportunities they provide. This article does 
not attempt to be a definitive reference of all 
technologies in use or proposed by BT for the 
local access network. It should, rather, provide an 
insight into some of the technological possi¬ 
bilities and their individual management con¬ 
siderations. The technologies have been chosen 
in order to highlight the main management issues 
associated with topology, media and anal¬ 
ogue/digital systems. 

A number of management considerations are 
common to all or many of the technologies. These 
include: 

$ configuration, capacity and geographical loca¬ 
tion of underground plant—manholes, joint 
boxes and duct; 

Q configuration, capacity, physical make-up, 
transmission characteristics, allocation and geo¬ 
graphical location of cables; 

• potential serving domain of distribution points 
(DPs); 

test access; and 

• inventory and performance aspects of element 
types. 

Single Pair of Metallic Wires 

This is the most basic of all technologies and the 
backbone of many more complex technologies. A 
single pair of wires is dedicated to an individual 
customer circuit. It has a star topology, with the 
possibility of multiple flexibility or cross-connec¬ 
tion points between the MDF and the NTE at the 
customer’s premises. The NTE for this 
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technology is a purely passive device. This tech¬ 
nology can be used to deliver POTS (plain old 
telephone service), Telex or private circuit ser¬ 
vices. (See Figure 1.) 

Specific management considerations include: 

• the configuration, capacity, pair allocation and 
geographical location of cross-connection points 
(MDF, primary cross-connection points (PCPs) 
and DPs); 

• the determination of transmission loss parame¬ 
ters given line length; and 

• the monitoring of cable pressure alarms. 

Metallic Pairs and Modems 

This technology uses the metallic pairs to trans¬ 
port data in analogue form (Figure 2). The 
modem is used as the conversion unit from anal¬ 
ogue to digital transmission. If the technology 
uses a single metallic pair, then it may be con¬ 
nected to a standard analogue line card in the local 
exchange to provide public switched telephone 
network (PSTN) access. It may also be used for 
low-data-rate private circuits. The use of two 
metallic pairs is another option for providing 
higher-data-rate private circuits. 

Specific management considerations include: 

• all those involved with single-pair metallic- 
wire technology; 

• remote soft configuration of the modem unit; 

• test access and diagnostics; and 
© event handling. 

Pair Gain—DACS1 

The Digital Access Carrier System No. 1 
(DACS1) is a two-channel technology providing 
analogue interfaces to the exchange and the cus¬ 
tomer, but using digital transmission between the 
units (Figure 3). The medium used is a standard 
single metallic pair. The NTE is a purely passive 
device. This technology can be used for access to 
the PSTN or for analogue private circuits. 
Specific management considerations include: 

• all those involved with single-pair metallic- 
wire technology; 

• configuration of multiplexing units to the 
single metallic pair; 

• logical/physical addressing of multiplexing 
units; 

• planning/feasibility given transmission loss 
parameters; 

• basic line test facilities of the metallic drop to 
customers, with the provision of mimic impedan¬ 
ces for exchange line testers, to enable the correct 
repair staff to be dispatched; and 

• monitoring of the digital transmission path. 

Fibre Access Network (FAN) 

With this technology, the customer’s premises are 
connected to the local exchange by optical fibre. 
This provides an access mechanism for several 
services (Figure 4). The connection comprises a 



MDF: Main distribution frame DP: Distribution points 

PCP: Primary cross-connection point NTE: Network terminating equipment 


Figure 1—Metallic pairs 



Figure 2—Metallic pairs and modems 


CUSTOMER 


TO EXCHANGE 



Figure 3—Pair-gain Digital Access Carrier System No.l (DACS1) 


number of fibres to allow diverse routing for 
reliability. 

The equipment at the customer’s premises 
comprises opto-electronics, high-order multi¬ 
plexers, line transmission protection switching, 
and common equipment, which together com¬ 
prise the network service module (NSM). 

The primary multiplexers consist of a series of 
line cards which provide the interface to the cus¬ 
tomer (via the building distribution frame) for the 
services required. These 64 kbit/s inputs are then 
multiplexed together for forward transmission via 
the high-order systems to the exchange serving site. 

At the serving site, the high-order systems are 
demultiplexed back down to 2 Mbit/s low-order 
systems. These are forwarded, via the bearer 
transmission network, to the service networks 
(for example, PSTN, X-Stream, or integrated ser¬ 
vices digital network (ISDN)). 

Specific management considerations include: 
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Figure 4 

Fibre access network 
configuration 



HOMUX: High-order multiplexer OLTU: Optical line terminating unit 


O configuration and allocation of elements— 
MUX, line card, optical end, NTE type; 

© state control of elements; and 
O automatic event reporting. 

Optical Fibre, Switched Broadband 

This is the technology employed in BT’s switched 
star cable TV network (Figure 5). The only extant 
installation is located in the City of Westmin¬ 
ster 1,2 . Video channels are multiplexed together 
and transmitted down optical fibres, four video 
channels per fibre. Some video channels are 
broadcast via the hub-site, which performs fan¬ 
out, to the wideband switch points (WSPs). Other 
video channels are sent via dedicated optical 
fibres to the WSP. The WSP converts the optical 


signals to electrical signals and feeds them to the 
inputs of the video switches. When a channel is 
selected by the customer, the appropriate switch¬ 
ing is performed by the WSP to provide the re¬ 
quired signal. The final link to the customer is via 
small-bore coaxial cable. Text generators in the 
WSP allow for customer interaction with infor¬ 
mation databases held at the head-end. 

Specific management considerations include: 

® configuration of subsystem control and data 
links; 

• configuration and allocation of subsystem ele¬ 
ments; 

0 serving area of WSPs and DPs; 

• monitoring and control of subsystem and ele¬ 
ment states; 


Figure 5 

Switched-star cable 
TV schematic 




OPT: Opto-electronic converter 


WSP: Wideband switch point 
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Figure 6 

TPON schematic 


© automatic event reporting for subsystem ele¬ 
ments; 

@ signal strengths; 

# performance aspects of element types; 

# remote update of the WSP database; and 

# passing information to control customer ac¬ 
cess to video channels and/or data services. 

TPON (House/Business) 

TPON 4,5 (telephony over a passive optical net¬ 
work) is a digital technology which uses optical 
fibres in a ‘tree’ topology and time-division multi¬ 
plex (TDM) and time-division multiple-access 
(TDMA) techniques (Figure 6). The opto-elec- 
tronics are used to separate the multiplexers from 
their line cards. This allows the MUX line card to 
be remotely located in the customer’s estab¬ 
lishment. For residential or house TPON, the 
NTE contains only a single line card. However, 
for business applications, the NTE can contain a 
number of line cards, each of a different type. The 
services provided by this technology are depend¬ 
ent upon the type of line card used, and the bit 
capacity allocated. 

Specific management considerations include: 

# potential serving domain of the secondary 
splitter; 

# configuration and allocation of elements; 
MUX, line card, bit capacity and position within 
TDMA, optical end, and NTE type; 

# state control of elements; 

# automatic event reporting; 

© attribute set up of the bit transport system 
(BTS) slave; and 

@ test access, including optical time-domain re- 
flectometry. 

Radio, Point-to-Point 

As Figure 7 shows, a multiplexer is remotely 
located at the customer’s establishment and 


linked by the use of a line-of-sight radio system. 

It is currently used only to provide MegaStream. 

Specific management considerations include: 

% geographical location of radio units and multi¬ 
plexer; 

© planning/feasibility by determination of line 
of sight, avoidance of interference to or from 
other systems, signal strength; 

© allocation of frequency; 

© configuration of the multiplexer; and 
© line card types, locations and allocation. 

Mobile GSM 

GSM (groupe speciale mobile) uses digital cellu¬ 
lar radio techniques to provide connection from 
portable or mobile telephones into the PSTN. The 
specification is common across Europe and will 
allow suitably authorised mobile telephones to 
access the system at any point in its coverage area 
across Europe. The system will allow data calls 
to be made as well as voice calls and also provides 
a paging service. 

Specific management considerations include: 

© base station site planning and cell coverage 
area determination; 

O cell frequency allocations; 

© GSM network planning and PSTN access Figure 7 
point determination; Radio schematic 
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€> mobile authorisation, both on first subscrip¬ 
tion and per call; 

© call accounting, charge determination and as¬ 
signment; 

Q system performance monitoring and refined 
coverage area determination; and 
© system growth planning and provision. 

Cordless DECT 

The DECT (digital European cordless telephone) 
standard provides for low-power digital portable 
radio telephones providing connection to a base 
station over a short range. The base station may 
be located in the home, connected to a standard 
telephone line, or may be located in a public 
place; for example, a railway station or motorway 
service area. In this case, only outgoing calls from 
the portable can be made. The technology can also 
be used to provide a PBX service. 

Specific management considerations include: 

© base station site planning and coverage do¬ 
main determination; 

© DECT public access network planning and 
PSTN access point determination; 

# portable authorisation on first subscription; 

© call accounting, charge determination and as¬ 
signment; 

0 system performance monitoring; and 
Q system growth planning and provision. 

MANAGEMENT CONSIDERATIONS 

The local access network is unique in at least one 
respect of its management requirements: the need 
to determine the potential network access points 
or points of sale with respect to a geographic 
identifier for the customer’s address, the postal 
address or map reference coordinates. 

It is likely that in the near future a given cus¬ 
tomer location may be served by more than one 
technology. Management systems must be able: 

© to identify the technologies capable of provid¬ 
ing the service required by the customer, and 
© to select between the different technologies on 
the basis of cost, reliability, performance and 
availability. 

In the event of insufficient capacity, the man¬ 
agement system should also be capable of mana¬ 
ging the provision of customer service via a 
relatively more expensive technology in order to 
satisfy an urgent requirement. This would be fol¬ 
lowed by supervising the planning and transition 
(at a later date) to a more cost-effective technol¬ 
ogy. For example, it may be possible to provide a 
customer’s circuit quickly via a radio-based tech¬ 
nology, while planning a change to a fibre-based 
technology. It may also be possible to upgrade a 
metallic-pair-based technology as a result of op¬ 
portunities presented by the introduction of pair- 
gain systems. 

The impact on the planning process of the 
presence of multiple alternative networks is likely 
to be considerable. 


In addition to the management considerations 
of the various technologies, future network and 
service management systems should also 
consider the issues of facilities required by the 
network operator: 

© Customers should be provided with a single 
point of contact for all their enquiries and calls for 
assistance. It should be possible once the cus¬ 
tomer has requested assistance to be able to re¬ 
spond rapidly to the customer, regardless of topic. 
Comprehensive work management facilities 
should be available to support field installation 
and maintenance activities. 

© Centralised network management centres 
should have the ability to test circuits remotely. 
By employing the techniques of routining, alarm 
gathering and ‘hot-spot’ analysis, these centres 
should also be capable of detecting any deterior¬ 
ation of service, ideally before, but at least as soon 
as, a customer experiences difficulty. It should 
also be possible for faulty circuits to be taken out 
of service automatically and the network manage¬ 
ment centre informed. Auto-transfer of service to 
back-up circuits should be undertaken where the 
technology in use allows for diverse routing. 
Wherever possible, maintenance tasks should not 
degrade the quality of service, and field mainten¬ 
ance activities should be minimised. 

© Strategic objectives for management systems 
should ensure that the system design is evolution¬ 
ary and expandable for the easy addition of new 
operational facilities and the management of new 
types of technology. In order to achieve this, the 
system design should conform to an overall tele¬ 
communications management architecture em¬ 
ploying international and open standards as these 
emerge. It will be this system design that provides 
a competitive edge for the network operator over 
its rivals. 

The ability of management systems to meet 
these objectives will depend on the underlying 
network technology in use, in particular the degree 
of built-in intelligence for monitoring and control, 
and equipment redundancy for fault-recovery. 

Network operators and the technology pro¬ 
viders of new equipment or services often have 
different perspectives of management require¬ 
ments. A technology provider would normally 
wish to sell equipment and an associated manage¬ 
ment system to cover all aspects of its use, from 
service management through to the operation of 
the network elements. The technology provider 
perceives a complete turnkey system as the best 
way to market his product, so he produces a 
vertical slice (Figure 8). This will contain an in¬ 
tegrated management capability, but for this par¬ 
ticular product only. The network operator, on the 
other hand, will have structured (or planned to 
structure) his operation in a layered fashion, in 
horizontal slices to provide a single customer-fac¬ 
ing point of contact for one-stop shopping , which 
is considered to be the key to fostering good 
relationships with customers. 
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The different perspectives of network operators 
and technology providers could both be addressed 
in the same system package from a technology 
provider. This would provide interfaces at the busi¬ 
ness level, service level and network control level 
to facilitate integrated working to satisfy the net¬ 
work operator, while still providing a complete 
turnkey operation for those who require this. 

The different technologies described above 
provide the network operator with many varied 
opportunities and challenges. With the different 
technologies available, and an integrated man¬ 
agement solution with customer access, it is likely 
that in the future the customers themselves will 
be able to configure new services without the 
intervention of the network operator. 

To reduce the provision time of customer cir¬ 
cuits, it will be necessary to ensure that as much 
of the time-consuming preliminary work as 
possible is carried out in anticipation of a cus¬ 
tomer order. With the growth of competition to 
supply even basic telephony service, improved 
efficiency must be given more attention. In the 
US, operators are increasingly employing the 
warm dial-tone concept, where new buildings are 
pre-wired and telephone sockets connected 
through to the exchange. The new resident plugs 
in a telephone purchased from the local store and 
is connected directly to the network operator’s 
customer service office. The new sale can be 
initiated immediately, with the required record 
changes, billing function, directory number allo¬ 
cation and service provision taking place auto¬ 
matically. To achieve this, a fully-integrated set 
of management functions must be in place. 

MANAGEMENT SYSTEMS 
ARCHITECTURE 

It is important that network management systems 
are developed to overall architectural standards if 
such systems are to interwork and to provide 
integrated network management and service ad¬ 
ministration across the network at all levels. Rec¬ 
ognising that the local distribution network is an 
integral part of the overall telecommunications 
network, it is important that management of the 
local network evolves within such an overall 
architectural framework. The following outlines 
a general architectural model considered from a 
local network viewpoint. 

The architecture for telecommunications net¬ 
work management is defined in terms of a hier¬ 
archy of five layers 6 , as shown in Figure 8. 
Starting from the bottom layer, the network is 
partitioned into network elements which are 
treated as distinct network entities from a man¬ 
agement viewpoint but which cooperatively pro¬ 
vide a service to the customer. 

As shown earlier, the local access network is 
made up of several managed element types; for 
example, network termination units, MUXs, ca¬ 
bles and DPs. Each network element has an asso¬ 
ciated element manager. This may, in practice, be 
a separate processor linked to the element, or 



Figure 8—CNA-M architecture—outline 


software embedded within the element. An ele¬ 
ment manager would normally manage multiple 
instances of an element. 

The network management layer, in turn, super¬ 
vises the various element managers. This is the 
first layer where the management relationships 
among elements are coordinated to provide over¬ 
all network and technology supervision. The in¬ 
terface between an element manager and element 
may be specific to that element type. The element 
manager ‘hides’ equipment variability from the 
higher network management layer. For example, 
there may be different types of modem in the 
network, all providing the same basic service, but 
requiring different control streams to configure 
them. The differences would be confined to the 
element manager level. 

This layering , applied to the components which 
form the local access part of the network, is exactly 
the same as that applied to the switching and trans¬ 
mission parts; the architecture is common. 

Work management facilities would be linked 
to this level to ensure that maintenance and repair 
activities are coordinated with network manage¬ 
ment. 

Thus the higher-level interface between element 
managers and network management is independent 
of particular equipment implementations. This ap¬ 
plication of the design principle of ‘layering’ 
achieves open network management whereby the 
network control level can develop independently 
of changes in underlying equipment. 

The interface between network and service 
management levels is defined such that service 
management need not know about the physical 
details of the network and need be concerned only 
with administration of the services that the net¬ 
work supports. Service management should have 
sufficient interaction with the network to allow 
comprehensive development of single-point-of- 
enquiry and one-stop-shopping administration fa¬ 
cilities. Refining this general model from a local 
network viewpoint, the elements making up the 
overall telecommunications network fall into two 
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Figure 9 —CNA-M architecture—local access 
perspective 


groups: those within the core segment and those 
within the access or local segment of the network, 
with their respective element managers. Coordi¬ 
nated supervision is necessary across the ac¬ 
cess/core segment boundary, and would be 
implemented at the network management level, 
as represented by Figure 9. 

Traditionally, different services have been car¬ 
ried on physically separate bearer circuits, par¬ 
ticularly in the local network. The management 
of the services and of the networks that bear them 
have often been common. In future, multi-service 
networks will be the norm, and services and net¬ 
works will have to be managed separately if the 
desirable layering structure is implemented 
across the network operator’s business. Agree¬ 
ments will need to be made between the service 
and network management units to ensure that the 
overall quality-of-service requirements of the 
customer are fully met. 

A model for technology-independent manage¬ 
ment of the local access network based on 
CNA-M (Cooperative Networking Architecture- 
Management) is currently under consideration. 
The model attempts to prevent diversification or 
duplication of effort, and the urge to re-introduce 
vertically segmented solutions when new techno¬ 
logies and services are developed. 

FUTURE WORK 

The model achieves technology independence 
through the functionality of the layers, the data 
contents of the layers, and the data definitions and 
relationships. The model defines the local access 
network using object-oriented techniques and the 
use of the Open Systems Interconnection (OSI) 
Network Management Forum object library. Data 
are passed between the functional categories and 
the layers by using the OSI Common Manage¬ 
ment Interface Protocol. 

The model uses the standard CNA-M network 
control layer functional categories: configura¬ 
tion, event handling, performance, access and 


security, planning, finance and resource manage¬ 
ment to achieve conformance with the architec¬ 
ture and to encourage reusability. 

It should be noted that changes will have to be 
made to the current management systems and 
processes if substantial benefits towards mana¬ 
ging the local access network in a technology-in- 
dependent manner are to be made. 

It may well be that, in future, the business case 
for the introduction of new proprietary techno¬ 
logies will include a requirement for the product 
to be capable of control by using the established 
management model, to ensure that BT maintains 
a coherent product set. 
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Alarm Management 

R. J. McFARLANEt 


This article gives an update on progress made in the area of centralised alarm management since the 
publication of the October 1989 Journal article ‘Centralised Exchange Management Using Gateway 
Products'\ The alarm management architecture for analogue and digital exchanges is given together 
with current and future developments of the Network Operations Management System 1 (NOMS1). 


INTRODUCTION 

Centralised exchange management and line test 
systems have been developed from the early-1980s 
to the present day by a small team of network 
engineers based in Edinburgh. This ‘Gateway’ 
team is now part of BT’s Development and Pro¬ 
curement Glasgow Engineering Centre. Since the 
1989 Journal article on centralised exchange man¬ 
agement 1 , the team has been involved in enhancing 
and supporting alarm management systems to meet 
the needs of the Network Administration Im¬ 
plementation Programme (NAIP). In particular, the 
Network Operations Management System 1 
(NOMS1), formerly the alarm collection facility, 
plays a key role in the fault and repair management 
area of network operations. Although NOMS1 is 
currently a standalone system, the potential for 
further improvements in alarm management and 
fault repair can be best realised by providing links 
to other systems used by engineers in network 
operations units (NOUs). Links from NOMS1 to 
NOMS2, the interim work management system, 
have been developed to meet current operational 
needs. However, the fault and repair management 
systems (FARMS) evolution will define the way in 
which NOMS1 will be linked in with other initia¬ 
tives, such as the problem manager workstation 
(PMW), to provide a coherent set of systems. 

EXCHANGE ALARM MANAGEMENT 
SYSTEMS 

Outline Architecture 

Figure 1 outlines a typical alarm management 
system deployed throughout the country. 

Reference 1 describes this architecture in some 
detail. A brief overview is now given. Alarms are 
collected from all types of exchange; for example, 
digital (TXD), electronic (TXE), crossbar (TXK) 
and Strowger (TXS). Examples of the type of 
alarms collected are: 

0 auto, 

# main control unit (MCU), 

0 power, 

• transmission equipment, 


t BT Development and Procurement 


CONTROL DUTIES 



ANALOGUE ALARMS DIGITAL ALARMS 


ACU: Alarm collection unit 
ARU: Alarm reporting unit 
LDS: Local display shelf 


0 cable pressurisation, 
© fire, and 
• intruder. 


Figure 1 
Topical alarm 
management system 


All exchange types have remote units located 
either in the exchange or in a nearby location. For 
analogue exchanges, the remote units are either 
Gateway REMPlus or Gateway H remote. For 
digital exchanges, this will be the alarm collection 
unit (ACU). These units have the same basic 
function; that is, to collect and forward alarms. 
Concentration of alarms is carried out before for¬ 
warding to NOMS1 by the alarm reporting unit 


218 


British Telecommunications Engineering, Vol. 10, Oct. 1991 
















































































(ARU) for analogue, and the local display shelf 
(LDS) for digital alarms. The alarm handling 
system (AHS) comprises the ACU together with 
the LDS. NOMS1 carries out a wide range of 
functions, some of which are listed below: 

© It provides alarm name translation. 

© It provides alarm delay. 

Q It distributes alarms to the relevant destination 
workstation; for example, TXE4, transmission, 
power and so on. 

# It filters alarms, giving visibility of alarms 
with a certain priority. 

© It attempts automatic alarm resets. 

Q It allows manual alarm resets. 

© It provides automatic alarm transfer when one 
destination logs off. 

© It provides interrelated alarms—alarms not dis¬ 
played until a user-defined threshold is reached. 

NOMS1 currently supports two formats of 
alarm messages: those from the ARU and from 
the AHS. The ultimate aim is to standardise the 
ARU message format to which new alarm man¬ 
agement systems must conform. 

Although Figure 1 shows only ARU and LDS 
as alarm inputs to NOMS1, other alarm collection 
systems have been deployed and perform the 
same function; CSX1200, SIGNALMAN, 
DAM5001 and REAMS, which feed alarms to a 
personal computer (PC) that inputs to NOMS1, 
are the other preferred systems. Several other 
systems are in use in addition to these. 

Figure 1 shows a link to NOMS2, which was 
implemented in V3.2 of NOMS 1. This link is not 
yet operational, and its implementation will be 
considered as part of the FARMS evolution in 
order to secure the maximum operational benefit. 
Introduction of an electrical link to work manage¬ 
ment will further automate the process of alarm 
handling. 

Managing TXE4s 

NOMS1 can remotely manage alarm reset and 
busy (ARAB) functions for TXE4 exchanges. To 
provide this functionality for TXE4s, a micropro¬ 
cessor-controlled unit has been developed to BT 
Figure 2 specifications. Figure 2 shows the ARAB connec- 

ARAB connections tion arrangements. 


TXE4 — 
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N0MS1 
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X.25 


<■ 


RESETS/BUSYS 
FROM N0MS1 


PSTN: Public switched telephone network 


TXE4 alarms are fed via the ARAB unit to 
the associated REMPlus which forwards them 
to NOMS1. In addition, 128 reset and 64 busy 
channels are provided to allow TXE4 equipment 
to be reset and brought in or taken out of service 
(busy) under control of NOMS 1 via the REM¬ 
Plus unit. 

ARAB Reset 

ARAB configuration is carried out by the data- 
builder and includes macros which allow equip¬ 
ment resets to be actioned from NOMS1 by use 
of a single key stroke; for example, the BUSY - 
reset - UNBUSY macro is used to reset MCU 
equipment in line with the TXE4 rule set. 

ARAB Busy 

TXE4 equipment is busied out from NOMS 1 by 
entering the NOMS1 name for the exchange 
equipment and selecting the ARAB busy func¬ 
tion. 

NOMS1 Platform 

NOMS1, under the name of the alarm collection 
facility, was initially developed on the M6000 
platform by using the C programming language 
with the UNIX operating system. As develop¬ 
ments in workstation technology progressed, the 
move to a SUN environment was taken. It should 
be stressed that the early decision to develop 
NOMS1 in the UNIX environment has greatly 
eased the task of moving the application to an¬ 
other hardware platform. The output display de¬ 
vice has also changed from alarm display PCs to 
M1779 terminals. The facilities provided by the 
change to Ml779s are: 

© the ability to interrogate alarm reports for any 
location within the NOMS1 database, 

€) visibility of active alarms allocated to other 
terminal users, 

Q alarm reset functionality integrated with nor¬ 
mal terminal usage, 

© no need to update every alarm PC when a 
remote unit name changes or is added, 

© alarm titles for remote units controlled cen¬ 
trally, and 

# more information passed to terminal users to 
reduce repetitive NOMS1 database queries. 

NOMS1 Roll-Out 

The roll-out of NOMS1 was completed in May 
1991 with 19 machines installed country-wide to 
meet the requirements of the 10 NOUs. Initial 
feedback from NOU engineers is as follows: 

# reduction in number of call-outs (approxi¬ 
mately 70% reduction), 

0 essential for NOMS1 to be operational 24 
hours/day, 365 days/year to provide visibility of 
alarms throughout the country, and 

# the need for standard alarm configuration for 
different exchange types. 
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Feedback is provided directly to the NOMS1 
support team from the users. As roll-out has pro¬ 
gressed, the level of support and feedback has 
greatly increased. Feedback provided to the sup¬ 
port team is recorded and results in a fault report 
or a facility change request being generated. 
These are used as inputs to the user-group meet¬ 
ing, which agrees the content of the next release. 

Operational Usage 

Each NOU has several control areas assigned to 
manage the network within its catchment area. A 
typical NOU control area layout is shown in Fig¬ 
ure 3 together with the support systems used. It 
can be seen that NOMS1 is the key system in 
providing visibility of alarms. Currently, the Cus¬ 
tomer Service System (CSS) is used as the means 
of allocating and actioning fault repair. TXS 
alarms are extended to the 24 hour control area in 
the NOU during out-of-office hours. 

LINKS TO OTHER SYSTEMS 

The need for a coordinated approach to alarm 
management has been recognised and is being 
addressed by the FARMS evolution study. 

FARMS will evolve the systems involved in 
fault and repair management, including NOMS 1, 
to provide comprehensive support to engineers in 
the NOU. Among its objectives are: 

Q to provide network engineers with a single 
‘picture’ of all alarms and faults within their 
catchment area, 

O to correlate fault reports from different sys¬ 
tems and facilitate automatic forwarding of work 
tasks to a work management system (WMS), and 
Q to provide a standardised approach to alarm 
and fault management. 

Figure 4 shows an early stage in FARMS evol¬ 
ution where the problem manager workstation 
(PMW) is the means of providing the overall 
‘picture’ to network engineers. NOMS1, trans¬ 
mission network surveillance (TNS) and the oper¬ 
ations and maintenance centre (OMC) are some 
of the systems from which the PMW will process 
and correlate fault reports. The PMW will for¬ 
ward diagnosed problems to the WMS for action 2 . 

NOMS1 FUTURE EVOLUTION 

NOMS1 will evolve to satisfy the requirements 
of the business on two levels: 



Figure 3—Typical NOU control area layout showing control duties 



PMW: Problem manager workstation 
CMIS: Common management information service 
NOMS 1: Network operations management system 1 
OMC: Operations and maintenance centre 
TNS: Transmission network surveillance 
WMS: Work management system 


(a) to be part of the NAIP vision of alarm 
management for the future (FARMS evolution), 
and 

( b ) to meet NOMS1 users’ short-term oper¬ 
ational requirements. 

The process of agreeing future enhancements 
to NOMS1 is now well defined and controlled. 
The opportunity exists for operational managers 
to become involved in the evolution of NOMS1 
by providing feedback on the suitability of propo¬ 
sals put forward at a strategic level. In addition, 


Figure 4 —Problem manager workstation 


operational managers are best placed in many 
instances to identify opportunities for making 
further improvements in alarm management. This 
may result in enhancements to existing systems 
or in identifying new systems that are required to 
help them meet their objectives. Any new systems 
may have only a short lifespan until strategic 
systems are realised and operational. It is hoped 
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that this top-down, bottom-up approach will en¬ 
sure that the needs of managers and engineers at 
all levels are met. Some proposed enhancements 
to NOMS1 are given to provide an indication of 
future direction: 

# multiple alarm displays, 

# support for enhanced TXE4 remote adminis¬ 
tration, and 

# provision of Cooperative Networking Archi¬ 
tecture (CNA) conformant interfaces to other sys¬ 
tems. 

CONCLUSION 

With NOMS1, alarm management has taken a 
large step forward in providing operational engin¬ 
eers with the tools they need to meet their objec¬ 
tives and thus providing customers with a 
first-class service. The scene is set to provide 
greater visibility of alarms from all parts of the 
network and to instigate action automatically for 
their repair. 
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The BT Network Traffic Giamagememi! System- A Window on 
the Network 

R. GARRISON!, A. SPECTOR, and P. C. DE GROOT* * 


Network traffic management involves supervising the telephone network and taking action to control the 
flow of traffic to maximise call success rates. The BT network traffic management system (NTMS) has 
been purpose-built for this role; it uses near real-time surveillance of network status and performance to 
enable prompt control of traffic flows as necessary. The development programme, started in 1982, has 
produced a world-class product, which is used for managing BTs inland network and has been sold 
successfully to Telefonica , the Spanish PTT, and Cellnet. This article describes the progress to date, and 
the functional characteristics of the NTMS, and explains why the NTMS is well placed to ensure 
improvement in network quality in the 1990s. 


INTRODUCTION 

All the world’s leading telecommunications oper¬ 
ators have come to realise that real-time surveill¬ 
ance and control of networks are essential for 
maintaining network service and providing 
quality to the customer. 

Modern network traffic management (NTM) 
was first identified at a conference of regional 
AT&T managers held in the autumn of 1960. 
Hurricane Donna hit Florida during the con¬ 
ference, and the increased number of calls from 
worried customers overloaded and knocked out a 
local common-control trunk exchange and con¬ 
gestion spread, tying up main switching centres 
throughout the US. Although many miles from 
Florida, the conference delegates experienced so 
much trouble contacting their families and col¬ 
leagues, that network management was added to 
their agenda mid-conference! 

An article 1 in the Journal by Steve Heap and 
John Arthur in 1985 explained that digital net¬ 
works, although resilient and self-regulating in 
some respects, are vulnerable to certain network 
failures and traffic conditions. Traffic overloads, 
such as the one initiated by the Florida hurricane, 
could not only cause failure of single network 
elements but could also lead to catastrophic ripp¬ 
ling effects throughout the whole network. Real¬ 
time traffic management was required to monitor 
the BT digital network, to identify these condi¬ 
tions and allow network managers to apply pro¬ 
tective or expansive controls to the network to 
maximise call completion rates and hence 
revenue. 

Since 1985, BT has implemented network traf¬ 
fic management systems (NTMSs) for both the 
inland and international networks, with the oper¬ 
ations for the whole network being combined at 
the Worldwide Network Management Centre at 


t BT Worldwide Networks 

* BT Customer Systems 


Oswestry over this period. The size of the moni¬ 
tored inland network has increased from 53 ex¬ 
changes with 8000 traffic routes to nearly 500 
exchanges with 40 000 routes. The current system 
requires reception and processing of over 
2*5 Mbytes of data every 5 minutes. NTM control 
facilities have also been introduced to allow rapid 
deployment of restrictive or expansive control 
actions to exchanges to control traffic flows. 

NTMS FUNCTION 

CCITT Recommendation E.410 defines network 
traffic management (NTM) as the function of 
supervising the network and taking action when 
necessary to control the flow of traffic. This re¬ 
quires real-time monitoring and measurement of 
current network status and performance, and the 
ability to take prompt action to control the flow 
of traffic. The primary objective is to enable as 
many calls as possible to be successfully com¬ 
pleted. This objective is met by maximising the 
use of all available network elements and by 
inhibiting and preventing the spread of conges¬ 
tion. 

In terms of the BT Strategic Systems Plan 
(SSP), the processes which cover NTM oper¬ 
ations fall within the ‘Manage Network Usage 
and Performance’ process and are: ‘Collect and 
Evaluate Network Traffic Information’ and, ‘In¬ 
itiate Solutions to Traffic Problems’. 

NETWORK TRAFFIC MANAGEMENT 
CONTROLS 

Network traffic management controls for System 
X and AXE 10 exchanges have been incorporated 
into operations and maintenance centres (OMCs) 
which are located at BT’s network administration 
computer centres (NACCs). The NACCs are 
linked to the Oswestry centre, thus providing net¬ 
work traffic managers with the ability to control the 
whole digital network from a central point. 
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There are two main types of traffic control 
available, expansive and protective: 

Expansive Controls 

Expansive controls, for example, temporary alter¬ 
native routing, are generally used to re-route calls 
that would normally succeed around a problem 
area, such as loss of a route. Temporary alterna¬ 
tive routing involves insertion of additional rout¬ 
ing choices into routing schedules so that calls can 
be redirected from congested routes to other, not 
normally available, routes which have idle capac¬ 
ity at the time. 

Protective Controls 

Protective controls, for example, call volume 
controls, are used to stop calls that are unlikely to 
be successful, to preserve network capacity for 
use by other revenue-earning calls which can 
succeed. Examples of calls that would be re¬ 
stricted are those to phone-in radio and television 
programmes, where the number of calls made far 
exceeds the call-handling capability of the reci¬ 
pients. Call volume controls inhibit calls to a 
particular digit string (destination volume con¬ 
trol), to a specific route (route volume control) or 
on an exchange-wide basis (exchange volume 
control). 

Although the CCITT Recommendations sug¬ 
gest that call volume controls be available on a 
percentage or call-rate basis, System X exchanges 
support only the call-rate control, commonly 
known as call gapping. Call gapping works by 
setting an upper limit on the number of call at¬ 


tempts allowed to a destination or route in a 
particular period of time T. The time T can be 
varied by the network manager to match the call 
handling rate of a called customer or service 
provider. 

A particular NTMS function which assists the 
use of call gapping is call analysis on destination 
or on routes, which can provide data on most 
commonly called destinations. Once this infor¬ 
mation is known, the network traffic manager can 
target the problem destination code(s) with the 
correct call-gapping rate. 


USING THE NTMS 

The essence of the NTMS is that network events 
are represented as clear, visual signals to the 
network traffic manager. Once an event is vis¬ 
ually acknowledged, the network traffic manager 
uses the workstation facilities to investigate the 
problem in further detail. 

The graphics display (Figure 1) is the primary 
display component, which is used to highlight 
those routes and exchanges that have a problem. 
The gravity of the problem is expressed in col¬ 
ours, red being the most serious and blue the least 
important. The graphics display also employs a 
split screen technique to display different sche¬ 
matic views of the monitored network at the same 
time. The left-hand view is the global display 
which shows a top-level schematic map of the 
monitored network and the right-hand view is 
used for user-selected displays; for example, a 
particular exchange catchment area. 


Figure 1 

Graphics display, 
showing split-screen 
operation 
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The VDU (see Figure 2) is used to display 
alphanumeric data on screens which correspond 
to the selection on the graphics display. These 
comprise tabular reports of exceptions, parame¬ 
ters and measurements which can be selected for 
the current and three previous periods. 

Using the system, the network traffic mana¬ 
gers are in a position to identify particular service 
difficulties that will not in themselves raise ex¬ 
change alarms, such as data inconsistencies or 
sudden changes in traffic patterns, and this win¬ 
dow on the network gives them the global view 
to enable decision making and fast control re¬ 
sponse. 

An increasing problem in telephone networks 
is the surge of traffic to a single destination or 
service provider as a result of a civil disaster or 
unexpected TV/radio phone-in. The result is a 
rapid increase of call attempts, most of which will 
fail, and a real risk that ‘focus’ exchanges will go 
into overload. 

In the case of the Heysel Stadium riot between 
Liverpool and Juventas football supporters in 
1985, the emergency number shown during the 
TV transmission represented a line connected to 
a single telephone in Brussels. The huge number 
of calls that followed caused disruption of na¬ 
tional and international communications from 
Liverpool and the failure of local exchanges in 
Liverpool itself. 

As the number of ineffective call attempts to a 
particular destination rises above certain thre¬ 
sholds, the NTMS displays the corresponding 
route exceptions as lines on the graphics display, 
which will focus on the exchange hosting that 
‘rogue’ destination. The network traffic managers 
then have to act quickly to identify and restrict the 
calls to that destination to protect both the net¬ 
work and normal revenue-earning calls. 

As experience of network traffic management 
has grown, the importance of pre-planning has 
been realised for known phone-in events; for 
example, Children in Need, Comic Relief and 
‘peaky’ customers such as travel agents and infor¬ 
mation lines such as Channel 4 Raceline. Uncon¬ 
trolled, these events would cause sustained 
overload of the network, leading to unacceptable 
levels of congestion and failure of switching 
nodes. By careful planning and knowledge of 
previous similar events, it has proved possible to 
anticipate problems and apply controls to the 
network before the start of events. 

SERVING THE CUSTOMER AND 
BUSINESS 

The driving force of network traffic management 
is to enable as many calls as possible to be com¬ 
pleted in any situation. By maximising the suc¬ 
cess of these calls, NTMS is impacting on how 
customers view BT and how they use BT services. 

When the network traffic managers apply pro¬ 
tective controls to the network to stop overloads, 
it seems that they are stopping customers from 
getting the service they expect. In fact, quite the 



opposite is true. By restricting calls that would 
normally have failed, they are assisting the suc¬ 
cessful flow of other calls. For those calls that are 
restricted, facilities are available to route them to 
recorded announcements which provide informa¬ 
tion on reasons why the calls were blocked or the 
best time to re-try those calls. 

By maximising successful calls, and main¬ 
taining or improving customer perception of BT, 
business needs will also be served. Maximising 
the number of successful calls means maximis¬ 
ing revenue and ensuring that capital investment 
in the network is being properly rewarded. At 
the same time, data being passed to capacity 
managers enables more accurate projection of 
future needs and direction of future capital in¬ 
vestment. 


Figure 2 
VDU showing 
example of tabular 
reports 


NTMS DESIGN 

The NTMS is connected to digital exchanges via 
the administration data packet network. Network 
traffic measurement data is transmitted to the 
NTMS every 5 minutes and the data passes 
through a number of processing stages before it is 
displayed to the network traffic manager. 

Software Structure 

The live NTMS software structure consists of 
seven main modules which enable the reception, 
processing and display of data from digital ex¬ 
changes. Data is transferred between modules 
using messages, common data areas and disc 
files. The monitored network and system configu¬ 
ration details are stored in a proprietary Reliance 
database. 

The main software modules and related data 
flows are shown in Figure 3 and are described 
below: 

# The system configuration module enables dif¬ 
ferent NTMS and monitored network configura¬ 
tions to be defined and maintained. 
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Figure 3 
NTMS software 
modules 



Note : The following have been omitted for clarity: 

Data flow lines from NTMS definition shared memory to all modules. 
Controls module. 



Figure 4—Typical NTMS workstation 


• The data reception and validation module 
checks the values and formats of measurement 
data and stores validated measurements in an 
exchange-independent format known as generic 
measurements. 

• The data analysis module uses the generic 
measurement data to derive generic parameters 
which are based on CCITT standards for traffic 
management; for example, answer seizure ratio. 
Selected parameters are compared against pre¬ 
determined thresholds and if the threshold limits 
are broken, an exception report is generated. Par¬ 
ameter and exchange/route exception priorities 
are calculated for all monitored exchanges and 
routes, and are placed in lists ordered in terms of 
severity. 

© The NTMS workstation module displays the 
generic measurements, generic parameters and 
exceptions in graphical and tabular form on the 
workstations, which comprise a colour graphics 
display with a mouse and a VDU with keyboard. 
(See Figure 4.) 

• The miscellaneous displays module controls a 
number of top problem and exchange status dis- 
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plays on the wallboard display system. The wall- 
board display system allows inland NTM data to 
be displayed with international and derived ser¬ 
vices network (DSN) NTM data together with 
service protection network (SPN) information on 
a large (5 x 30) back-projection TV wall display. 
Q The data archive and playback module stores 
parameter and exception data on magnetic tape to 
record network conditions which can be replayed 
later. The archive and playback operations can be 
run concurrently with the live traffic management 
operations. 

% The OTIS (on-line traffic information system) 
module collects and transmits network configura¬ 
tion and generic measurement data to the OTIS. 
The OTIS computer collates the data into daily 
and weekly summaries which can then be used for 
longer-term capacity management and for net¬ 
work planning. 

Two other modules, the network simulation 
module and the controls module are used to simu¬ 
late the behaviour and control of a switched com¬ 
munications network in real time for training or 
study purposes. 

Hardware Configuration 

The NTMS software runs on Concurrent Compu¬ 
ters 3200 series 32-bit mini computers, which can 
be in either a single machine or a multi-machine 
configuration. The multi-machine configuration, 
which is used for the live NTMS, consists of a 
number of machines operating as front-ends , hand¬ 
ling data reception and processing, and one ma¬ 
chine, known as the back-end , which controls the 
displays, operator requests and database access. 


In this configuration, a multi-port RAM disc is 
used for bulk data transfers between the ma¬ 
chines, the non-bulk data being transferred by 
using an Ethernet local area network provided by 
Concurrent Computer Corporation’s RTnet. 
RTnet also provides an interface to external com¬ 
munications; that is, X.25 across wide area net¬ 
works. Each workstation consists of a Tektronix 
4225 graphics display with mouse and a Tandberg 
TDV2200S series VDU with keyboard. 

Operating System 

The operating system used is Concurrent Com¬ 
puter Corporation’s OS/32, which provides a real¬ 
time, event-driven environment for the NTMS 
modules, which are run as one or more OS/32 
tasks. 

NTMS IMPLEMENTATION 

The NTMS in the BT network has been im¬ 
plemented as a single centralised system, with 
operations being based at the Central Operations 
Unit at Oswestry (see Figure 5). This approach 
has the following advantages over distributed 
operations: 

# It enables a ‘global view’ of network perfor¬ 
mance which permits faster and more accurate 
problem identification and the development of 
more effective control strategies. 

S It is more effective in dealing with complex, 
interrelated problems in the stored program control 
(SPC) and common-channel signalling environ¬ 
ment. A centralised approach simplifies the prob¬ 
lem of coordination of activities in these cases. 



Figure 5 

The Worldwide 

Network 

Management Centre 
at Oswestry showing 
the operations room 
with wallboard 
display system 
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# It provides a single point of contact for net¬ 
work traffic management, both internally and 
with other operators and administrations. 

PROGRESS TO DATE 

The success story of the BT network traffic man¬ 
agement system is one of vision, energy and com¬ 
mitment of designers, developers and project 
managers to ensure quality of design and im¬ 
plementation. As an example, the original speci¬ 
fication called for handling data from GPT 
System X exchanges, but the flexible design has 
also enabled other types (Ericsson AXE 10 and 
AT&T 5ESS exchanges) to be connected. 

The major milestones in the NTMS project to 
date have been as follows: 

1982 The BT Board decided to sponsor the 
development of a prototype. The ex¬ 
perience gained from this early test¬ 
bed system was incorporated into the 
development of a full-scale NTMS. 

1985 A live NTMS entered service, moni¬ 
toring the UK digital trunk network. 

1986 Facilities were introduced on SEP2 
System X exchanges which enabled 
dedicated network management 
measurements to be output in binary 
form by using X.25 communication 
links. 

1988 An interface was provided to AT&T 
5ESS Phase 2 (5E3) exchanges. The 
administration data packet network 
was launched, which enabled large 
numbers of exchanges to be con¬ 
nected to the NTMS via a common 
interface. 

1989 Provision of traffic control facilities 
applied via OMCs. 

1990 The Worldwide Network Manage¬ 
ment Centre opened at Oswestry, 
which brought together both inland 
and international network manage¬ 
ment operations. The NTMS4.2.3 re¬ 
lease enabled the whole inland digital 
network to be monitored every 
5 minutes. 

The most recent release, in June this year, 
provided facilities for monitoring AXE10 ex¬ 
changes and for accurate destination analysis to 
identify ‘problem’ numbers. 

FUTURE DEVELOPMENTS AND VISION 

The development plan in place will enable the 
NTMS to evolve to continue monitoring an ex¬ 
panding digital network, with the addition of an 
interface to the next build of AT&T’s 5ESS ex¬ 
changes by March 1992. A major development 
due at the end of 1992 will provide generic control 
facilities for all exchange types, together with 
updated workstations to access ancillary support 


systems. The development will also enable pro¬ 
tective controls to be broadcast to selected parts 
or all of the network near-simultaneously for con¬ 
trol of unexpected focused overloads. 

The proposed system will incorporate other 
network management support systems, to reduce 
duplication of data and system function. The first 
stage will be to combine the functions of the 
NTMS and OTIS onto a common platform. This 
will allow the NTMS direct access to historical 
data to aid human, or later machine-based, deci¬ 
sion making, which is currently under investiga¬ 
tion by BT. The proposed system will also form 
the platform for amalgamation of the inland and 
international NTMSs. 

MIGRATION STRATEGY 

As with any system that has been operational for 
a number of years, careful thought must be given 
to the evolution of the underlying technology. 
Over the lifetime of the NTMS, the major change 
in technology in the market-place has been the 
shift away from proprietary architectures towards 
Open Architectures. This has happened at both 
the software level, where Unix has been adopted 
as the standard operating system, and at the hard¬ 
ware level, where manufacturers are making in¬ 
creasing use of commodity chips. 

At the same time, BT has formulated Co¬ 
operative Networking Architecture (CNA) stand¬ 
ards, based on ‘open’ systems, which is being 
used as the basis for all further support systems 
development. 

The overall benefits to the business of migra¬ 
tion to open systems are significant. It enables 
standard software packages (such as BT CNA 
generic software) to be used in place of cus¬ 
tomised developments. It enables much better 
integration with other support systems and it also 
opens up a wider choice of suppliers. The cost 
savings of commodity hardware over proprietary 
hardware are substantial. 

As far as the base technologies of the NTMS 
(hardware and operating system) are concerned, 
the major strategic direction proposed is to move 
away from the Concurrent proprietary architec¬ 
ture, towards an open architecture, based on Unix. 
The migration will be based on planned and future 
operational enhancements to the NTMS, requir¬ 
ing the NTMS to move through a period where 
both architectures exist in a hybrid configuration. 

The future NTMS application software will be 
based on object-oriented design (OOD); that is, 
software will be constructed from a number of 
pre-built components, rather than designing and 
building the system down from a unique set of 
requirements. There are a number of advantages 
to this approach, the main ones being reusability 
(from release to release and from system to sys¬ 
tem), flexibility and robustness. 

OOD advocates the combination of data and 
procedural elements into objects which may be 
derived from the applications or design domains. 
Examples of application domain objects are 


British Telecommunications Engineering , Vol. 10, Oct. 1991 


227 





entities such as exchange, route, network and 
concepts such as performance parameter and ex¬ 
ception. Objects are combined into classes, which 
represent the common behaviours of the objects. 
An information model is constructed which 
defines the behaviour of each class and the rela¬ 
tionships between various classes. 

During object-oriented component design, 
each class is designed internally, and coded and 
tested. During object-oriented system design, ob¬ 
jects are combined into physical entities such as 
tasks, subsystems and so on. This is the bottom-up 
part of OOD, and is a relatively small part of the 
overall analysis and design process. 

Some OOD work has already been undertaken 
in the form of a pilot project, which has resulted 
in a number of reusable components, some of 
which are already planned for reuse in future 
releases. 

The migration of the base technology will also 
enable a migration to a proposed software architec¬ 
ture which will provide significant operational im¬ 
provements. These will include the ability to view 
a network in a number of different ways, the ability 
to monitor a number of networks or network mod¬ 
els simultaneously, and full flexibility on the types 
of analysis that could be performed concurrently on 
a selected basis. For example, two additional types 
of analysis could be retrospective busy-hour or 
trend analysis, and rule or knowledge-based ident¬ 
ification of network problems. 


The proposed software architecture, shown in 
Figure 6, is split into three major parts, perfor¬ 
mance, configuration and planning. Performance is 
concerned with collection and analysis of perfor¬ 
mance data from network elements. Configuration 
is concerned with application of controls to net¬ 
work elements. Planning and design is concerned 
with the modelling and simulation of networks. 

In the longer term, one aim is for the exchange- 
specific parts of the system to be replaced by a 
telecommunications management network 
(TMN). The TMN will provide an organised net¬ 
work structure, incorporating a standard set of 
messages and interfaces, which will enable the 
interconnection of network support systems and 
network elements. 

CONCLUSIONS 

BT has the capability to manage its UK and 
international networks using NTM systems, 
which will become increasingly combined and 
conformant with open architecture standards. The 
next few years should see the consolidation of 
these trends as the NTMS is developed further 
with additional functionality and with new ex¬ 
change interfaces as required (for example, 
Northern Telecom DMS100 to be used for the 
advanced services unit). Investigations are also 
underway to determine the requirement for man¬ 
aging the CCITT No. 7 signalling network, as 



Figure 6 
Future NTMS 
software architecture 
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new services are becoming more and more sig¬ 
nalling based. 

The global ‘window on the network’ provided 
by the NTMS enables rapid detection and analysis 
of adverse traffic conditions to aid application of 
‘healing’ actions to maintain or improve network 
service. 

The ability to control networks in this way will 
become increasingly important with deregulation 
and introduction of more competitors. Customers 
will be won or lost on the ability to maintain a top- 
quality and resilient network. 
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Data and Configuration [Management 

R. M. BATYt 


Data management of stored program control telephone exchanges is a vital aspect of operation of a 
telecommunications network. The services provided to customers both now and increasingly in the 
future are dependent on having an effective data management organisation. This article describes 
how BT manages the data on its System X and AXE 10 switches in its digital trunk and local network. 


INTRODUCTION 

The service features that are offered to customers 
by a telecommunications operator are largely 
determined by intelligence built into the net¬ 
work’s stored program control (SPC) telephone 
exchanges. The specific features offered to custo¬ 
mers are tailored by means of the configuration 
data built into the exchange processor or, in the 
case of modern intelligent networks, into attached 
processors. This article describes how the data for 
BT System X and AXE 10 digital exchanges is 
built and managed. 

Discussion often centres on the functionality 
of systems, but the problems associated with data 
building and management must not be underesti¬ 
mated. 

DATA TO BE MANAGED 

A modem SPC telephone exchange is made up 
from three elements: 

(a) hardware (including firmware), 

( b) software, and 

(c) data. 

The data defines how the above exchange ele¬ 
ments are configured as follows: 

Customer Data This defines the facilities pro¬ 
vided to the customer; for example, call itemis- 
ation, night busying, PBX line hunting, signalling 
type, integrated services digital network (ISDN), 
preference category, subscribers private meter etc. 

This data is specific to each exchange and 
group of customers; it will tend to be of a simple, 
repetitive nature for residential customers, but 
can be complex for business customers. 

Network Data This defines the network and 
its facilities connected to the exchange; for 
example, routes, circuits, signalling systems, host 
and remote concentrator topology, dialled digit to 
hardware route translations, alternative routing 
facilities, charging and tariff definitions, traffic 
and performance statistic production etc. 

This data is essentially exchange specific, but 
there tends to be significant commonality be¬ 
tween exchanges of a similar type. 


t BT Worldwide Networks 


System Data This defines the internal archi¬ 
tecture of the exchange and its processor in a 
similar way to a computer operating system; for 
example, input-output (10) channels and devices, 
alarm outputs, application software subsystem 
dimensioning etc. This has a high degree of com¬ 
monality across exchanges of a similar type. 

For all of the above three, the data must link 
hardware and associated software to provide spe¬ 
cific implementations of customer, network and 
system facilities. For a typical 60 000 line tele¬ 
phone exchange, the data volumes are as follows: 

Customer data 9 Mbyte 

Network data 0-5 Mbyte 

System data 01 Mbyte. 

Clearly, with the quantities of data described 
above, this is a significant task. 

DATA LIFE CYCLE 

The life cycle of exchange data is split into two 
distinct phases: 

(a) Data Build This is the phase prior to an 
exchange being brought into service; it largely 
consists of a data collection and cleansing cycle 
followed by loading this data on to the exchange 
processor and ensuring that the data-build rules 
of the exchange are adhered to. This process is 
known as data fill in North America. 

(b) Data Management This is the phase 
after an exchange has been brought into service; 
it consists largely of managing the data to reflect 
chum and growth in customers and the network 
together with the provision of new and enhanced 
facilities. It also includes ensuring that the data is 
kept in a systematic and coherent format. 

The data-build process may be carried out by the 
equipment supplier under a turnkey contract or, as 
in the case of BT, by the network operator. After the 
exchange has gone into service, it is normal for the 
network operator to manage the data. 

SYSTEM X AND AXE10 DATA 
INTERFACES 

Both System X and AXE 10 have man-machine 
interfaces (MMIs) which conform to CCITT 
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Figure 1 
System X and 
AXE10 data 
interfaces 


recommendations and give data (10) interfaces in 
ASCII format. They both also have 10 interfaces 
to their processor memories which enable system 
archives and reloads to be made in a binary format 
via magnetic media. The AXE 10 MMI is a high¬ 
speed one and is the sole interface for data inputs. 
System X also has an off-line facility, the data 
compiler-decompiler (DCD) which enables oper¬ 
ations to be carried out on the data elements of the 
system archive. The data interfaces for System X 
and AXE 10 are shown in Figures 1 (a) and 1(b) 
and are described in further detail below. 

SYSTEM X DATA MANAGEMENT 

A typical System X man-machine language 
(MML) input is shown in Figure 2. This input 
may be from either a terminal connected to an 10 


IN - DDC ; 163 - K 1 010081,11,6,4, , ,137; 


INSERT 


DIGIT DECODE 


DESTINATION 
CHARGE GROUP 
(BAND 37) 


POINT OF ENTRY 


MINIMUM NUMBER OF 
DIGITS LESS NATIONAL NUMBER 


NATIONAL NUMBER 


DIFFERENCE BETWEEN MINIMUM 
AND MAXIMUM DIGITS. 


DIGIT TRANSLATION TYPE 


This command inserts a new entry into the digit decode 
(dialled digit to route translation). The example shown is the 
addition of ISDN access to Japan where the national code is 
010081, the total maximum allowable digits is 16 and the 
minimum number 10. The charge group (band) for the dialled 
digits is 37. The dialled digits will access the spinal digit 
decode tree at point of entry 163. 

Figure 2—Typical System X MML command 


Q_Q ARCHIVE 



(a) System X data interface 



(b) AXE10 data interface 

DCD: Data compiler-decompiler RALF: Remote archive and load facility 

MMI: Man-machine interface VDU: Visual display unit 

OMC: Operations and maintenance centre 


port via the operations and maintenance centre 
(OMC), a file applied from the OMC or an obey 
cartridge connected directly to an 10 port. The 
obey cartridge interface is more secure than the 
direct terminal interface particularly for bulk in¬ 
puts of hundreds of lines of MML as it uses 
handshake techniques to ensure commands are 
entered correctly before the next one is accepted. 
Both the OMC and System X itself have had 
macro commands developed which provide 
single functions derived from a series of interde¬ 
pendent MML commands. This technique mini¬ 
mises the probability of errors occurring when 
data is updated and is used on the OMC sub¬ 
scribers record system for both simple single-line 
transactions and complex PBX management. 

The DCD operates in a similar fashion to a 
software programming language compiler-de¬ 
compiler. It runs off-line from the exchange on a 
Digital Equipment Corporation VAX mainframe 
computer system and enables bulk data inputs to 
be compiled into exchange processor executable 
format and vice versa. The man-machine DCD 
inputs and outputs are in a computer-punched 
card flat file format known as BA cardformat. As 
the interface between DCD and the exchange is 
via the processor 10, this enables a high-speed 
data 10 to be established for System X. This 
interface between the exchange and DCD can be 
either via a magnetic cartridge or via an electronic 
interface known as the remote archive and load 
facility (RALF). As the DCD runs on an off-line 
mainframe, it is possible to perform powerful data 
manipulation on the system data such as is re¬ 
quired when reparenting a concentrator from one 
processor to another. When the data has been 
manipulated off-line, it can be reapplied to the 
exchange processor using the data transfer pro¬ 
cess. The DCD also checks for data consistency 
and is used to ensure that any data that has been 
applied via the MMI has not got into an inconsist¬ 
ent state. Outputs derived via the decompiler are 
also used to audit the exchange data to ensure that 
it is correct. 
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ANBSI;B = 256-0908,RC = 602.CC = 1.A = 1.TR0 = 908,L = 10,0 = 2 - 0; 


COMMAND 

IDENTITY 


HI 


ROUTING 

CASE 


NUMBER 

STRING 


ACCOUNTING 

CASE 


NUMBER 

LENGTH 


ANALYSIS 

AREA 


ANALYSIS 

LOCATION 


CHARGING 
CASE 

TRAFFIC DESTINATION 

DESTINATION CASE 

CASE 


This command is a dialled digit analysis command known as 
B-number analysis. The example shown defines the call 
routing, charging and number length for dialled digits 0908 
(Milton Keynes). Also included are parameters defining 
network management, call barring and network operator 
revenue apportionment facilities. 

Figure 3—Typical AXE10 dialled digit analysis 
command 


(a) a complete new processor with associated 
concentrators, 

(b) a processor extension and additional con¬ 
centrators, 

(c) an additional new concentrator, or 

(d) the extension of an existing concentrator. 

The process is assisted by a series of computer 
tools that have been developed within BT for both 
System X and AXE10. Schematics of the data 
flows through these systems are shown in 
Figures 4(a) and 4(b). 

For both System X and AXE 10, a PC-based 
tool, the data allocation and build system 
(DABS), is used to collect and cleanse the cus¬ 
tomer data and to allocate the customers to par- Figure 4 
ticular concentrator hardware. A PC-based Data-build process 


AXE10 DATA MANAGEMENT 

A typical AXE10 MML input is shown in 
Figure 3. This input is either from a terminal 
connected to an IO port via the OMC, a file 
applied from the OMC or a personal computer 
(PC) compatible floppy disc connected to an IO 
port. AXE 10 has powerful facilities for manipu¬ 
lating the data on the exchange processor. The 
data can be set up and tested in a non-operating 
area before it is brought into operation. If it is 
required to manipulate the data off-line, such as 
for an extension or for audit purposes, the data is 
taken off the exchange as a print file in ASCII 
format on to a floppy disc. AXE10 uses a support 
environment, running on an IBM mainframe 
computer, that enables a set of standard data-build 
files to be maintained which are used to assemble 
bulk data inputs for its MMI. This support envi¬ 
ronment includes TRAFDATA, a system supplied 
by Ericsson used for syntax checking of MML 
prior to it being loaded on the exchange. 

DATA-BUILD PROCESS 

At the planning stage of the conversion of an 
existing analogue exchange to a digital exchange, 
a definition is made of the customers and network 
that is to be replaced, including any allowances 
for growth. This definition is a major input to the 
exchange design. The design of the replacement 
exchange in terms of configuration and topology 
may be quite different to the exchange to be 
replaced. Typically, a digital exchange uses high- 
capacity digital circuits, and this enables the total 
number of circuits, in particular direct links, to be 
reduced. The exchange design is then passed to 
the equipment supplier who produces a hardware 
design. The hardware design is a major input to 
the data-build process. At the same time, there is 
a process of collecting and cleansing the customer 
and network data. The requirement to have 100% 
correct data prior to bringing an exchange into 
service necessitates a thorough exercise to ensure 
that the new exchange data aligns with the anal¬ 
ogue exchange that it is replacing. The new unit 
that is being installed may either be: 


NETWORK 

DATA 


CUSTOMER 

DATA 


STANDARD 

CONFIGURATION 

FILES 



(a) System X 


STANDARD 

CONFIGURATION 

FILES 



(b) AXE10 


DCD: Data compiler-decompiler OMC: Operations and maintenance centre 
DABS: Data allocation and build system SRS: Subscriber records system 
FRS: Frame record system 

LLIS/FR: Local lines information system/frame records 
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- Fast Entry Line Record Editor - 

TXD DABS3 FES VI. 2 NNI:1234567 

Exchange : WBORO Cluster: 1 
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Line Type DBDXKii 
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“ ( 
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2 65 




DIS Clear 0 
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0 

13 SPM 
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Y 


Div Accept 
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Abb Dir Acc 
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Recal1 

Y 
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Remind 

Y 




BA121 AMEND BA122 AMEND 

Repeat 
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Screen Index - 
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Intercept Ctrl 

PREF 3 


- 

-> Entry 

Hon Bill 


Busy List Ctrl no 




Bar & Divert 

Call Walt 



Busy List no 




Frames 


Char Mode: Replace Page 1 


Count: 


Typical DABS system is ideal for this type of application as this 

input screen stage of the process tends to be a standalone one 

carried out by one person. The DABS has a series 
of input screens for different types of customers, 
a typical input screen is shown in Figure 5. 

The DABS has algorithms built in to give 
optimum allocation of customers across the ex¬ 
change so as to take into account load balancing 
and security considerations; for example, where 
possible, a large PBX is shared across more than 
one concentrator for security, and PBXs that nor¬ 
mally produce high traffic are allocated so that the 
load is balanced across concentrators. Also at this 
stage, customer facilities such as subscribers pri¬ 
vate meters (SPMs) are allocated as required. 

The output from DABS is used in conjunction 
with another PC-based system, the frame record 
system (FRS), to produce a jumper allocation 
schedule for the main distribution frame. Depend¬ 
ing upon the size and type of the new unit, this 
process can typically take between 6 and 12 
months. 

At the same time, the network and system data 
are collected and built to reflect the exchange 
design. In the early days of the digital exchange 
modernisation programme, a tool similar to 
DABS, called REDS , was used to collect the 
network data for System X via a series of input 
screens. The experience gained by field data- 
build staff showed that this process could be 
speeded up by simply copying an existing ex¬ 
change data build and modifying with a text editor 
such as WordStar. Such a text editor has powerful 
block copying and deletion facilities and ex¬ 
changes of significant variation of size and design 
can be built up from standard modules. This tech¬ 
nique ensures that the core architecture of proces¬ 
sors, alarms, circuit allocations etc. are kept to 
standard designs. In the case of System X, a PC- 
based tool, called the bulk vetter , is used to check 
that the inputs are syntactically correct before 
being compiled for application to the exchange. 

The hardware data for System X is provided 
as exchange name documents , and for AXE10 as 
route allocation charts. 


DATA MANAGEMENT PROCESS 

After an exchange has been brought into service 
or extended, it must be kept up to date with chum 
in both customers and the network. In addition, 
there is a continuous process of providing new 
and enhanced facilities including revised tariff 
structures. 

A city centre exchange can have customer 
chum of up to 25% or more per annum; this is 
equivalent to a complete change of customers 
over a four year period. Routine customer data 
management is carried out via the OMC sub¬ 
scriber record system (SRS), which provides a 
user-friendly interface to both System X and 
AXE 10, and requires only limited skill levels to 
operate. A very small percentage of specialist 
customer facilities, such as complex PBXs, re¬ 
quire direct MML to implement them. Should 
such facilities become common then the cost of 
developing the necessary SRS macros will be 
justified. 

The modernisation of BT’s public switched 
telephone network (PSTN) has seen a transition 
from an analogue to a digital network. This 
changeover in the network has necessitated care¬ 
ful data management to ensure that the quality of 
service is maintained. A significant part of this 
work has included data management operations 
such as: 

© growing the trunk network of digital trans¬ 
mission circuits between digital main switching 
units (DMSUs) as the analogue trunk network is 
taken out of service; 

% re-parenting transmission circuits between 
digital local exchanges and analogue group 
switching centres (GSCs) to DMSUs; 

# bringing new circuits into service to meet traf¬ 
fic growth requirements; 

# developing a network that includes automatic 
alternative routing choices for traffic under high- 
load conditions; 

providing call blocking facilities to restrict 
traffic to specific destinations and so prevent fo¬ 
cussed overloads on switching nodes; and 

# scheduling traffic recording data to ensure a 
balanced loading of the network. 

All of the above requires careful control to 
ensure coordinated implementation and an audit 
trail which confirms implementation back to the 
originator. The necessary control for such net¬ 
work-wide changes is provided from the central 
operations unit (COU) at Oswestry. Network 
changes are controlled by means of a network 
change request (NCR) database which provides 
details of the change to be implemented and sign- 
off facilities for the necessary audit trail. In par¬ 
ticular, it is essential that any changes associated 
with tariffs and charging are 100% accurate and 
that there is a signed-off audit trail to verify this. 
As an additional safeguard, tariff and routing data 
are audited on a monthly basis to ensure com¬ 
pliance with the central definitive source of such 
data, the national charging database. 
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DATA DESIGN 


The services that are the feature of modern net¬ 
works, for example, integrated services PBXs, 
intelligent networks and premium services, are 
built by tailoring the exchange application pro¬ 
cesses by means of data designs produced by 
central design teams. 

CAPACITY MANAGEMENT 

An important part of the data management pro¬ 
cess is to ensure that the exchange processor and 
its associated hardware are loaded correctly. This 
is done by processing data extracts taken from the 
exchange and monitoring the usage of hardware 
and software resources across the exchange ele¬ 
ments. BT tends to load its processors up to the 
capacity limit specified by suppliers; for example, 
60 000 lines per processor. Many other adminis¬ 
trations do not load so heavily; some administra¬ 
tions rarely go above 20 000 lines. This calls for 
careful monitoring and balancing of the exchange 
elements. In order to maintain this balance, it may 
be necessary to re-parent switch concentrators 
and circuits from one processor to another, or in 
the case of System X from one processor cluster 
to another. 

VISION 

The long-term vision for data operations in the BT 
network is to have maximum automation to en¬ 
able rapid error-free implementation of data 
changes at minimum cost. To this end, several 
operational support systems are being developed 
within BT as follows (see Figure 6): 

National Charging Database (NCDB) This 
system holds all the data necessary to define the 
charging in the UK PSTN network including that 
required for international calls. It is the single 
definitive source of this data. It includes inter¬ 
faces to enable automatic download of tariff ta¬ 
bles for modem exchanges. 

Charging and Routing Data Verification Utility 
(CARDVU) This system audits the charging and 
routing data held on modem exchanges against that 
defined by the NCDB. It includes electronic data 
interfaces to both exchanges and the NCBD to 
enable comparisons to be carried out. 

Network Routing Management System 
(NRMS) This is a routing model of the BT 
PSTN which includes physical routing data. It is 
capable of setting up routing schemes for the 
PSTN, including ‘what if’ models. 

Network Numbering Management System 
(NNMS) This provides a management system 
for numbering in the BT network. 
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OMC: Operations and maintenance centre 
EDMS: Exchange data management system 


Remote Data Loading Facilities 

Facilities are being provided, hosted on the OMC, 
which enable centrally prepared and audited files 
produced by off-line systems, such as those listed 
above, to be loaded on to System X and AXE 10 
exchanges from central locations such as the net¬ 
work operations units. This enables data manage¬ 
ment to be carried out from a minimum number 
of centres. 


Figure 6 

Charging, routing 
and numbering 
management and 
verification 


CONCLUSIONS 

The data management of SPC exchanges in BT 
will continue to evolve as it has over the last eight 
years towards an increasingly automated environ¬ 
ment. This will enable a feature-rich network to 
be built which can be manipulated rapidly and 
accurately to provide customers with the increas¬ 
ingly sophisticated and flexible services they de¬ 
mand. 
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Performance Assessment Tools 


R. L. HAWTIN, and E. JACKSONt 


Performance assessment is the key to success in a competitive environment. This article outlines the 
functions involved and explains how processes required to support these functions are being developed 
within a strategic framework. Some processes need to be automated and supported by computer systems. 
One such system , the evolving long-term log analysis product , is described in this article. 


INTRODUCTION 


System Framework 


To continue to develop and grow within the com¬ 
petitive UK telecommunications environment, 
BT must market services which are seen by cus¬ 
tomers to be significantly better than the alterna¬ 
tives. But, how does BT meet its objectives of 
delivering the best competitive services of the 
correct quality all the time? 

One key aspect is to measure the quality and 
performance of services delivered—the essential 
feedback loop. In classic total quality manage¬ 
ment (TQM) terms, if you cannot measure it, you 
cannot improve it. 

Business processes and support systems are 
required to enable and automate these feedback 
loops; a common technical framework 1 is re¬ 
quired to allow the systems to form part of a 
consistent, but flexible, world-class solution. This 
article describes the performance assessment 
tools which are being developed to support this 
function. 

Objectives 

Some of the areas where performance monitoring 
and performance assessment tools can be applied 
are described below: 

® to monitor the quality of service(s) to a cus¬ 
tomer; 

# to provide a health check on the network and 
provide data to the network operation and plan¬ 
ning process; 

© to review equipment trends and provide data 
to purchasing and network design decisions; 

• to review supplier performance and provide 
data to supplier management; 

• to monitor the man-machine language (MML) 
operations performed on the network and check 
that only authorised changes have been applied; 
and 

# to measure the cost and duration of key pro¬ 
cesses and workstrings. 


t BT Development and Procurement 


What is the vision as far as performance assessment 
is concerned? How can useful information be cre¬ 
ated for managers from a vast quantity of raw data 
produced from tens of thousands of sources? 

The idealised performance monitoring system 
needs to: 

@ monitor: 

—service quality, 

—cost of quality, 

—equipment/element, 

—circuit/link, 

—people, 

—processes and timings, and 
—suppliers; 

• assemble and manage large quantities of raw 
data and process different sets of data into the 
minimum required useful information; 

• combine data of different types from different 
sources to provide optimum input to decision 
making; 

• enable information to be customised and dis¬ 
played for different users; 

• allow problem areas/issues to be investigated 
by focusing monitoring onto the suspect target 
and increasing the power of the ‘lens’. 

The essence of such a system is that it supports 
the users in making decisions. Comprehensive 
data collection and automated, flexible process¬ 
ing will mean that the users have access to the 
information they need to make the decision. Their 
time is spent thinking about the options, not in 
collecting the base data. 

A representation of such a system is shown in 
Figure 1. The data sources (for example, ex¬ 
changes) provide a stream of information which 
is ‘picked off’ by different users (for example, a 
regional maintenance manager or national pur¬ 
chasing manager). Data streams are combined 
and processed to provide the information they 
need for their particular job. One of the key as¬ 
pects of such a system will be a flexible user 
interface which enables different views and op¬ 
tions to be explored. 
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Figure 1—Flexible data collection and processing 
/ system 


NETWORK SUPPORT SYSTEMS 

The major business initiative influencing the 
evolution of network support systems is the 
Strategic Systems Plan (SSP). 

A previous article 2 identified performance as¬ 
sessment systems (PAS) as one of the strategic 
system areas (SSAs) within the network support 
system architecture. The monitor, audit and ana¬ 
lysis elements described previously lie within the 
SSP third-level process ‘Manage Network Usage 
and Performance’. It is supported by tools within 
the PAS SSA. The repair elements are supported 
by tools contained within the Fault and Repair 
Management Systems SSA (FARMS SSA). Cur¬ 
rently, in excess of 20 systems perform functions 
in the PAS area, but they have been developed to 
a significant extent in isolation from one another 
and with a lack of overall structure. 

How do we get from the current position to the 
vision of the system framework described earlier? 

The Network Control Architecture Board 
(NCAB) has launched a PAS evolution study 
(PASES) team, similar to that for testing de¬ 
scribed elsewhere in this issue 3 , to provide a 
coherent strategy and architecture for the key 
support systems within the PAS SSA. 

The study team will produce the following 
deliverables: 

(a) a fully defined information engineering 
facility business model (containing SSP pro¬ 
cesses down to level 6 or 7); 

(b) a PAS logical architecture document out¬ 
lining the target logical functional blocks and data 
stores of the SSA; 

(c) a PAS physical architecture document out¬ 
lining the target physical realisation of the logical 
architecture; and 


(d) evolution-path documents detailing the 
evolution path for each key support system and 
manual process within the PAS business area. 

This study will result in a reduced number of 
performance systems which will support the busi¬ 
ness areas identified by the SSP and conform to 
an approved architecture. 

Some of the areas which need to be monitored, 
as identified in the performance assessment vi¬ 
sion, are addressed by current systems and these 
will now be described. 

LONG-TERM LOG ANALYSIS SYSTEM 

Reference 2 outlines a system that is already 
providing key functionality for the PAS SSA and 
is also a key data source for the FARMS SSA. 
This is long-term log analysis (LTLA), deployed 
on the digital exchange support system (DESS), 
and known as DESS LTLA. 

LTLA is already used to monitor MML trans¬ 
actions which change sensitive exchange con¬ 
figuration data. 

The LTLA performance assessment tool is de¬ 
scribed in more detail here. 

LTLA DATA CAPTURE 

Modem digital exchanges generate large volumes 
of administration data relating to call charging, 
traffic handling, fault management and configu¬ 
ration control. This data is polled by computer- 
based data collectors, stored, and forwarded to the 
relevant data processing system. 

LTLA receives and processes the data subset 
relating to internal exchange fault management 
and the MML used to change aspects of the ex¬ 
change configuration (see Figure 2). This is 
known as the exchange log. 



NETWORK 
ADMINISTRATION 
DATA COLLECTOR 


- ELECTRONIC LINK 

■ - - - MEDIA LINK 
O - MAGNETIC TAPE 


Figure 2—LTLA in the network 
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Data volumes are relatively high—in excess of 
350 Mbyte/day is currently processed—and at 
present the forecast maximum is 570 Mbyte/day. 

This data is loaded into a suite of databases for 
subsequent processing. From this historical rec¬ 
ord, occurrences of events can be pinpointed in 
detail both within a specific exchange, and to a 
specific time. 

SECURITY AUDIT 

All MML input is inspected automatically on 
receipt, and selected details associated with cer¬ 
tain specific events are logged immediately for 
subsequent investigation. 

The results of this analysis may indicate defi¬ 
ciencies in the operations and maintenance ma¬ 
nuals supplied with the exchanges, that additional 
training is required, or that the exchange data is 
being modified without the appropriate authority. 

PERFORMANCE ANALYSIS 

Within the core of the exchange, hardware is 
replicated and the exchange endeavours to recon¬ 
figure automatically around a fault. The faulty 
equipment still has to be identified and repaired, 
as the exchange is then vulnerable to subsequent 
faults of a similar nature. 

On the exchange periphery, hardware is not 
replicated. A fault on a line card may deny several 
customers access to the complete network. This 
represents a fatal degradation in the quality of 
service being provided to those customers. 

It is clearly necessary to detect and restore 
such service outages quickly. This day-to-day 
management is the role of the operations and 
maintenance system 4 which works in real time. 
However, it is also necessary to check if there is 
a pattern to such failures; for example, is there a 
suspiciously high failure rate among the entire 
population of a certain type/version/supplier of 
this line card? This requires national data analysis 
of a large amount of historical data. Such off-line 
processing represents a load that is best provided 
by a specialist host environment. 

LTLA analyses a wide range of fault reports to 
identify those having the most significant impact 
on the network performance. The analysis is per¬ 
formed on a national, zonal, and, if required, 
per-exchange basis. The results are made avail¬ 
able to the exchange product support groups, and 
performance-monitoring duties. Such analysis 
can often identify failure patterns which can be 
used to predict and avoid similar major failures. 

PERFORMANCE INDICES 

A number of measurements are defined as perfor¬ 
mance indices. For example, the time taken to 
clear hardware faults is analysed. This is the time 
taken to return manually the faulty equipment to 
service. Software too may not act as intended and, 
if the level of software errors becomes excessive, 
the exchange may automatically initiate recovery 
action. 


If the exchange processor is performing re¬ 
covery activity, it is not providing service by 
setting up new calls; DESS LTLA measures this 
element of lost processor time. 

DEVELOPMENT AND SUPPORT 
STRATEGY 

The developers have adopted a policy of incremen¬ 
tal builds, with several releases per year in order to 
combine worthwhile levels of enhancement with 
early availability of new functions requested. The 
software is run on large DEC/VAX computers at 
the Ipswich computer centre (DESS Central) and 
product support is provided by a separate team at 
BT Laboratories, Martlesham Heath. 

LTLA ENHANCEMENTS AND 
EVOLUTION 

While LTLA is not a real-time system, this does 
not mean that the business can afford to wait for 
the results of the analysis. The faster a generic 
problem is detected, the quicker it can be dealt 
with. Development work is in hand to provide 
on-line access to the database suite and to increase 
further the speed with which data can be captured. 

LTLA could be extended to process data from 
additional sources; for example, TXE4(E), inter¬ 
national exchanges and the advanced switching 
units. 

FAST-TRACK TOOL DEVELOPMENT 

There are times when the business cannot wait for 
a detailed requirements definition and subsequent 
specification and design stages covering all fore¬ 
seeable eventualities. Functionality may well be 
required earlier. This can be particularly true for 
performance assessment, where it is not until 
some data has been analysed that it is possible to 
tell if there is a problem. 

The solution is to restrict the initial product 
functionality to the minimum required, and re¬ 
strict data capture to a small catchment area. 
Products can then be realised on a small, readily 
deployed computer (PC) by using ‘encapsulated’ 
software. This consists of well-proven and do¬ 
cumented modules which can be assembled to 
provide the limited functionality initially needed. 
Subsequent ‘bespoke’ developments can then 
provide the finer detail, and in turn generate more 
‘encapsulated’ software for future reuse. 

Software originally developed for an ex¬ 
change maintenance data processor that acted as 
an intelligent data logger for System X has sub¬ 
sequently been reused to develop analysis fa¬ 
cilities for AXE10 traffic statistics (ASP). 

FUTURE OPPORTUNITIES 

The PASES study will identify the key systems 
required by BT in the PAS SSA and lay down the 
evolution plan to reach an integrated set of systems. 

The new tools to support usage and perfor¬ 
mance management processes are now being 
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realised using open computing platforms with 
powerful graphical interfaces. This gives flexi¬ 
bility to provide information to the users in the 
best way to assist their tasks. 

The need to capture and analyse data is not just 
restricted to managing the BT core network. The 
performance of any service being offered in a com¬ 
petitive environment must be measured to ensure 
continuing customer satisfaction. 

All parts of BT are working together to achieve 
the company’s mission of providing world-class 
telecommunications services. To underpin this, 
the various units are setting up service level 
agreements (SLAs) to document the standards 
expected of their interfaces with one another. The 
performance against these SLAs will have to be 
measured, analysed and managed to ensure that 
BT can carry out its mission. 

The importance of performance assessment 
systems in the future should not be under-esti¬ 
mated. 

CONCLUSION 

There are two quotes relating to this field that are 
well worth bearing in mind: ‘What you measure 
gets done’—Iain Vallance, Chairman of BT; and 
from Dr W Edwards Deming, one of the TQM 
gurus ‘You do not have to do this—survival is not 
compulsory.’ 
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Network Test IManagement Systems 

C. F. REEDt 


In September 1990, the Network Control Architecture Board commissioned three evolution studies into 
discrete areas of computer application concerned with network administration. This article describes one 
of those studies, namely the Test Access and Management Systems Evolution Study (TAMSES) and the 
architecture for test access and management systems produced by it. 


INTRODUCTION 

As described in a previous article 1 , the Network 
Control Architecture Board (NCAB) is respon¬ 
sible for the evolution of network support systems 
within Worldwide Networks. The NCAB has 
adopted the Network Support Systems Architec¬ 
ture (NSSA), which details the main areas of 
computer support for the network control level 
and their interrelationships. Those areas, termed 
strategic systems areas (SSAs), are groups of 
computer systems which have been identified by 
an NSSA top-level design team as having close 
affinity in the processes performed and in the data 
used. Figure 1 is reproduced from that previous 
article. 

The basis for the NSSA was the top-down 
analysis of BTUK performed by the Strategic 
Systems Plan (SSP) team, now known as the 
Business Process Unit (BPU). The BPU has now 
identified 17 business areas within the BT busi¬ 
ness model, of which four fall within the manage¬ 
ment area of network operations: 

® test management, 

0 network configuration, fault and repair, 

• traffic and performance management, and 
0 network capacity assignment. 


• to identify and document the present network 
testing capability; 

0 to identify shortcomings in that ability and 
rationalise the business needs; 

© to produce a target architecture for the im¬ 
plementation of ‘Test the Network’ processes 
within Worldwide Networks, consistent with the 
rest of the business and with the BT business 
model as defined by SSP; and 
Q to recommend a migration strategy for the 
development of test management systems. 

TAMSES addressed the computer support for 
testing which is currently used primarily for 
remote test control of line and circuit testing. 
However, TAMSES also addressed all other net¬ 
work testing including transmission, switching 
(but not internal self-testing by switches) and 
service testing. 

THE CHALLENGE 

BT’s current test management capability has 
evolved in an ad hoc fashion as test technology 
has emerged in specific areas. It is therefore frag¬ 
mented, confined within artificial geographical 
and technological boundaries, and expensive to 
run. 


The Test Access and Management Systems 
Evolution Study (TAMSES) is one of three initial 
studies into the following SSAs: 

• test access and management systems (TAMS), 
0 fault and repair management systems 
(FARMS), and 

• network configuration and data management 
systems (NCDMS). 

Studies of all 14 SSAs and the associated 
network data will be progressed in due course. 

In the case of TAMS, there is no difference 
between the test network business area and the 
test access and management systems SSA. 

The objectives of the TAMSES study were: 

• to confirm the functional architecture/inter¬ 
faces recommended by the NSSA top-level de¬ 
sign team; 


t BT Development and Procurement 


There is functional duplication between some 
test systems, although geographically discrete. 
The support costs can be reduced. 

The field maintenance units require accurate 
test information; accurate in the sense that faults 
are localised by the tests applied so that the work¬ 
force can be correctly despatched first time every 
time. Currently this is not achieved. 

The current test capability is concentrated on 
testing network elements for maintenance pur¬ 
poses, typically reactive maintenance after the 
customer h$s complained (too late!). There is 
little routine testing targeted at identifying degra¬ 
dation. 

The major challenge is to introduce an ad¬ 
vanced diagnostic capability and nightly routine 
testing of all local lines. 

This is to be accomplished as an integrated part 
of the NSSA solution where tests are automat¬ 
ically invoked, the test results are automatically 
correlated with cable routing information by 
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Figure 1—Network Support Systems Architecture 































































































































































Figure 2 
Overview of the 
current (1991) 
physical architecture 


FARMS, followed by efficient workforce des¬ 
patch by force and work management systems 
(FAWMS). 

A significant challenge is to introduce testing 
of all aspects of a service which affect the cus¬ 
tomer’s perception of that service. 

There is also a need to improve customer as¬ 
surance; that is, the ability to assure individual 
customers of the quality of the service actually 
given. 

Most of the testing performed is parametric 
testing on the local copper network. The core 
network (transmission and switching) is hardly 
tested at all under remote test control, except for 
circuits during provisioning (although it is con¬ 
tinuously monitored). 

The testing that is performed is ultimately re¬ 
stricted by the test access of the network and the 
capabilities of the measurement devices. Addi¬ 
tional test access is extremely costly (owing to the 
number of points of attachment to the network that 
is required) and was outside the scope of this study. 


There is no ability for synchronised test events 
to occur; the capability of end-to-end testing is 
therefore low. 

CURRENT ARCHITECTURE 

The current architecture is summarised in Fig¬ 
ure 2. The main systems are described below in 
respect of their test capabilities only. 

Remote Access and Test Equipment 
System (RATES) 

RATES 2 provides the primary testing capability 
for analogue private circuits. It consists of two 
types of equipment, namely the RATES manage¬ 
ment system (RMS) and the test access equipment 
(TAE). TAEs provide the means of access to 
analogue private circuits and the test capability 
itself. The RMSs perform the control and user 
interface functions and are linked via Packet 
SwitchStream (PSS) to enable coordinated test¬ 
ing of each stage of a given private circuit. 
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Digital Access Remote Test System 
(DARTS) 

DARTS provides the primary diagnosis and fault 
clearance confirmation test capability for 
KiloStream private circuits in the UK that are 
routed via automatic cross-connect equipment. 

Line Test Systems (LTS) 

Four line test systems are used: Gateway, Vande- 
rhoff, Teradyne and Northern Telecom. Each 
works in a similar fashion utilising metallic test 
access to customers’ 2-wire lines. Each system 
has obtained one quarter of the total number of 
exchange connections. Each system performs 
parametric testing of analogue public switched 
telephone network (PSTN) lines, but there is not 
a common test specification or standard. Each 
drives the System X local exchange sub-system 
test network via V.24 ports. Each has a proprietary 
user interface typically used in repair service cen¬ 
tres and each has an interface to Customer Service 
System (CSS) repair handling. 

Operations and Maintenance Centre 2 
(OMC2) 

The OMC2 provides a control interface into the 
System X test network via the administration data 
packet network. It is used for customer access 
testing, including pair-gain systems and ISDN 
IMUXs via Digital Access Signalling System 
No. 2 (DASS2), and trunk and junction circuit 
testing used by circuit provision control duties. 

Customer Service System (CSS) 

CSS is designed to support field staff in the cus¬ 
tomer-facing activities concerned with the provi¬ 
sion of PSTN service. It includes the repair¬ 
handling system, which allows front offices to 
invoke line tests using the LTSs. Depending on 
the results, the report is given a despatch code as 
appropriate. If there is no need for further cus¬ 
tomer contact, the report is sent to the back office, 
where a second iteration of diagnostic testing is 
initiated prior to despatch. 

THE VISION 

The vision is of a TAMS infrastructure offering 
an optimised portfolio of tests and capable of 
verifying that instances of BT’s network elements 
and services conform to the specified design and 
operational requirements at minimum cost. 

It will enable definitive statements regarding 
BT’s ability to meet contractual obligations to in¬ 
dividual customers or their representatives regard¬ 
ing quality of service and network performance. 

Detection of faults and service degradation 
prior to customer dissatisfaction will be achieved 
through flexible, targeted, efficient and standard 
control of a total network test capability to per¬ 
form continuous network surveillance of all local 
lines by scheduled testing. Optimum use will be 
made of test equipment and network resources. 


The test capability will be available on demand 
at all times and to all authorised users from any 
part of the BT network with minimised manual 
intervention. The test capability will be unified 
across all types of switching systems and access 
technologies. 

Fault localisation by on-demand testing will 
facilitate 100% despatch accuracy. The set-up and 
post-processing delays of all testing will be mini¬ 
mised. All on-demand tests initiated by customer¬ 
facing users will be accomplished in no longer 
than 10 seconds. 

Open interfaces will allow international co¬ 
operative testing and competitive procurement, 
and will aid the integration of new tests, new 
network elements and services into the TAMS 
infrastructure. 

TARGET LOGICAL ARCHITECTURE 

Information engineering (IE) is a methodology 
which enables business requirements capture and, 
subsequently, all manual and/or automated acti¬ 
vities to be streamlined. The first phase of the IE 
methodology, information strategic planning, 
was adopted in the production of the SSR The 
second phase, business area analysis, was used in 
the evolution studies under the NCAB to enable 
the integration of computer applications and to 
avoid the duplication of data. 

Business area analysis involves the identifica¬ 
tion of a data model, a process model, and their 
relationship by interaction analysis. More infor¬ 
mation is available in Reference 3. 

A computer-aided software engineering 
(CASE) tool—information engineering facility 
(IEF)—was chosen for the evolution studies. IEF 
was used as a structured repository for the infor¬ 
mation collected, to maintain consistency check¬ 
ing of the information and to perform matrix 
analysis of the assembled information. 

Process Model 

The first task for the study was to produce a 
process decomposition of the three component 
processes assigned to Test the Network’ by SSP 4 , 
namely: 

O Schedule Test, 

Q Control Test Sequences, and 
® Maintain Testing Information. 

It was decided that a further two levels of 
decomposition would confirm the validity of the 
parent processes and add sufficient detail. 

The decomposition produced initially by using 
the developing team’s knowledge and intuition 
was subsequently modified to take account of 
information assimilated from a wide range of 
interviews conducted with field personnel. 

The process decomposition is given in Figure 3. 
This defines the distinct processes that may be 
performed in the course of progressing a test re¬ 
quest. Not all may be relevant to every test, but 
similarly any one may be needed a number of times 
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Process 
decomposition 
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during a test. Each component process is logically 
unique but may need to be replicated in a physical 
implementation to achieve throughput. The layout 
of Figure 3, although apparently in time sequence, 
does not imply this order of processing. 

Data Model 

The data model, summarised in Figure 4, was 
created in parallel with the process model. The 
data entities identified represent the types of data 
that will be required by the TAMS systems. The 
figure also shows the relationships between the 
entity types. The notations on the relationship line 
further describe the relationship. Vertical bars and 
crow’s feet convey cardinality: whether the rela¬ 
tionship is one-to-one, one-to-many or many-to- 
many. The letter O on the line indicates that a 
relationship is optional. 

In general, when a test request is received, it is 
vetted against test initiator data and scheduled 
according to the availability and capability of test 
equipment, which has to be configured according 
to the accessibility link. The request will be for a 
test of a specified test class to be performed on a 
specified test object. Each test performed will 
create an instance of test data which is modified 
as the test is progressed through the various test 
states in its life cycle. 

Test class data includes the scripted proce¬ 
dures for each type of test which may contain 
conditional statements. 

Test classes are either simple or compound ; 
simple tests are the most elementary tests that can 
be invoked. Compound tests use two or more 
simple or compound tests to fulfil a more complex 
test requirement. 
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Business Processes 

These identify the flow of processing which oc¬ 
curs within, and supports the functions required 
of, TAMS. This includes the progression of tests 
from request reception through to test deletion. It 
consists of strings of processes and the informa¬ 
tion which is required to pass between those pro¬ 
cesses (data flows). Figure 5 shows the level 4 
business process of ‘Test the Network’. Others 
were created at level 5 and at level 6. 

Interaction Analysis 

Having agreed the component processes and data 
entities, the next step was to decide on the inter¬ 
action between them; that is, the effect that com¬ 
ponent processes have on the data entities in terms 
of creating, reading, updating and deleting them. 
The CASE tool produced information on the logi¬ 
cal association of processes due to the affinity 
between processes in the use of the data. 

Target Logical Architecture Design 

Identifying opportunities to optimise the cluster¬ 
ing of processes also due to their interaction with 
the network gives Figure 6, a diagrammatic rep¬ 
resentation of the processes and data combined 
which is consistent with the flow of information 
identified by the business processes. It is not part 
of the IE methodology but a view which is con¬ 
sistent with the contents of the process and data 
models. 


TARGET PHYSICAL ARCHITECTURE 

Generic Test Controller 

The target logical architecture could be im¬ 
plemented in many ways. It was realised that, in 
this case, it would be realised not by breaking up 
the target logical architecture, but rather by repli¬ 
cating it in a network of generic test controllers 
(GTCs), each GTC being the physical implemen¬ 
tation of the target logical architecture. 

This approach: 

# allows the provision of a common level and 
presentation of the testing service, 

• allows the provision of an end-to-end testing 
capability, and 

• facilitates compound tests built up from simple 
tests following test scripts. 

Open Interfaces 

Adopting an open interface between GTCs, and 
between GTCs and test equipment, allows: 

® migration away from proprietary interfaces 
where beneficial, 

© a clear separation between reusable test con¬ 
trol systems and dedicated test equipment, and 

# development and procurement of network ele¬ 
ments and/or test equipment independent from 
the test control. 


In August 1991, the OSI/NM Forum Test Man¬ 
agement Function Specification 5 was approved as 
an agreed specification for implementation by 
Forum members in preference to any intercept of 
the International Standards Organisation (ISO) 
Test Management Function Standard which will 
only become an international standard by mid- 
1992 at the earliest. The GTC interface will be 
aligned with the OSI/NM Forum Test Manage¬ 
ment Function Specification as BT is working to 
Forum specifications where no stable standards 
exist. 

The OSI/NM Forum Test Management Func¬ 
tion Specification will be a stable specification 
which should be close to that of the final ISO test 
management international standard because each 
of these specifications have influenced the other. 
The Forum will provide a controlled migration 
from the Forum specification to the ISO standard 
when it becomes available. 

The Forum and ISO specifications are both 
interface standards and as such do not define the 
internal representation of the test management 
data. The data held and transferred within the 
GTC needs to be of a consistent format. However, 
it is advantageous if the internal data format is the 
same as that used across the external interface to 
eliminate the need for translating the data formats 
for external communications. 

This study has confirmed the technical feasi¬ 
bility of the use of the emerging standard test 
request and test response messages as candidates 
for becoming the primary inputs and outputs to 
GTC (and TAMS in general). 

Description of Simple-Test Execution by 
a Single GTC 

The scheduling engine receives and validates the 
test request, checking: 

® the requester’s authority to invoke that specific 
test, and 

© whether that test is in the current test portfolio. 

By reading the test class data, it identifies that 
the test is a simple test and assesses the current 
capability to perform that test by reading from the 
test equipment and accessibility link data. 

Following the test script of that particular test 
class, it then ascertains and books required net¬ 
work and test equipment resources prior to sche¬ 
duling the requested test at a time which will 
make efficient use of those resources while still 
satisfying any user specified time constraints. 

Finally, it must report the success or otherwise 
of scheduling the requested test. It creates the 
specific test instance by using the test class as a 
template and modifying default settings as re¬ 
quired. 

The execution engine monitors the scheduled 
start time of each test and begins execution of 
tests at the scheduled wake-up times. This execu¬ 
tion starts with the establishment of the pre¬ 
booked resources and continues with the 
generation of test commands to test equipment. 
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Figure 5—Top-level workstring 
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CAS: Customer accounting systems 
CNTE: Corporate network test executive 
FAWMS: Force and work management systems 
PAS: Performance assessment systems 


FARMS: Fault and repair management systems 
CSAMS: Customer service access management system 
NCDMS: Network configuration and data management systems 
TCMS: Traffic capacity management systems 


For a simple test class, these test commands do 
not involve any conditional decisions. 

Raw test results are then received/retrieved 
from the test equipment. After the active testing 
phase of the simple test, this engine releases the 
remaining test equipment and network resources. 

The interpretation and reporting engine uses 
the predefined interpretation criteria from the test 
instance to analyse the raw test results. It also 
must initiate the procedure to adjust customer 
bills where appropriate. 

After inteipretation, the required results must be 
reported to all identified recipients and then stored 
with the predefined storage time identification. 

The test information engine provides data 
management for the target logical architecture 
(TLA). It allows for updating of any of the test 
reference data (that is, test equipment, test class, 
accessibility link, test object and test initiator) as 
test equipment/test classes are added, subtracted 
or modified. It continually updates the data re¬ 
garding availability and utilisation of test equip¬ 
ment. Finally it monitors the storage times of test 


instances, deleting them when they are no longer Figure 6 
required. Target logical 

This engine gives both internal and external architecture 
users the facility to request a wide range of test 
reports on almost any aspect of TLA-held data. In 
particular, it can provide a list of the tests avail¬ 
able. This enables systems external to TAMS to 
offer their users menus and forms at the 
man-machine interface. 

Description of Compound-Test 
Execution by Multiple GTCs 

Figure 7 illustrates the interaction between two 
GTCs. 

The sequence is similar in concept. From the 
test class, the requested test is identified as a 
compound test and the test script retrieved gives 
the instruction to request the distant GTC to per¬ 
form a simple test within a time window. 

The distant GTC receives the request for the 
simple test and goes through the sequence ident¬ 
ified above. Once scheduled it reports the ability 
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Figure 7 
Example 
interconnection 
between generic test 
controllers 


to perform the test at a specific time-slot within 
the requested window. 

The near-end GTC then schedules the remain¬ 
ing procedures of the compound test. The near¬ 
end GTC has created a test instance for a 
compound test and the distant-end GTC has cre¬ 
ated a test instance for a simple test. 

The window of active testing at the near end is 
within the active testing window of the far end. A 
report of the ability to perform the compound test 
is returned to the requester. 

At their wake-up times, both ends initiate the 
establishment of their respective test environ¬ 
ments and proceed with their test commands. 

Once the active testing phase at each end is 
completed, the environments are de-established. 

The near end interprets the result of the com¬ 
pound test taking account of the (raw) test results 
provided by the distant GTC. The distant GTC 
stores the test result of the simple test, as required; 
the near-end GTC reports and stores the com¬ 
pound test result as required. 

It should be noted that the request made of the 
distant GTC need not be confined to a simple test, 
nor need the testing be confined to two GTCs. 


Description of Interactive Test 
Execution 

Some testing is not fully contained within the 
confines of TAMS and will require interactive 
testing; for example, 

© speech monitor paths, 

# transmission event monitoring, and 
<1 interaction with call control. 

Essentially, in each case the GTC testing 
procedure will be as described above to apply 
the correct stimulus, but the test requester will 
be required to observe the response to the stimu¬ 
lus. 

THE FUTURE 

At the time of writing, the business model as 
produced down to level 6 is at the stage of draft 
for approval by NCAB and the Business Process 
Unit. Once approved, it will be incorporated in 
the BT business model, and then becomes subject 
to the BPU’s change control. 

TAMSES has produced a migration strategy 
for existing test systems and proposals to improve 
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coordination of the testing process across the 
network. 

The concept of tests run according to scripted 
procedures means that the test control of new tests 
and new equipment can be enhanced and in¬ 
creased in due course by creating the required test 
scripts. The following paragraphs describe some 
developments already under way (the require¬ 
ments for which have been confirmed by the 
TAMSES) which can be exploited using generic 
test control. 

Transmission and Connectivity Tester 
(TACT) 

TACT is a transmission and connectivity test¬ 
ing specification planned to be offered for com¬ 
petitive tender in late-1991/early-1992. It will 
primarily test the quality of both national and 
international PSTN dial-up connections for 
both statistics gathering and maintenance pur¬ 
poses. 

TACT employs two types of test head unit; 
namely, transponders and responders. Although 
initially attached to dedicated test numbers, these 
units will have the capability to use test access to 
each customer’s 2-wire line at the interface to the 
main distribution frame (that is, the same test 
access as the LTS). 

Transponders initiate and manage all test calls 
to responders via a proprietary protocol and are 
themselves managed by a controller over a fixed 
or dial-up control connection. Controllers too are 
to be coordinated to ensure maximum access to 
responders. 

Test heads provide the normal connectivity 
measurements as a consequence of the dial-up 
process prior to the connection phase of the test 
call. Once connection is made, a subset of the 
available parameters will be measured. The sub¬ 
set will be variable according to the purpose and 
constraints of the required test. 

The measurable parameters are as follows: 

• transmission loss versus frequency and level, 

• idle-channel noise, 

• impulsive noise, 

• total distortion including quantisation distor¬ 
tion, 

• group delay versus frequency, 

• round trip propagation delay, 

@ echo, and 

• clipping. 

By specifying limits for the test results ob¬ 
tained for each parameter, simple pass/fail type 
statistics can be provided. 

These might be more useful for customer-fac¬ 
ing staff, raw data being retained by the control¬ 
lers for use by personnel involved in trend 
analysis of fault finding/repair. 

By adding a level of generic test control above 
the TACT controller level it would be possible to 
control transmission and connectivity testing be¬ 
tween any two customers (though the allocation 
of the connection will not be controlled). 


Event and Test Management System 
(ETMS) 

BT Business Communications requires a com¬ 
bined test control and alarm handling system to 
unify access to all private circuits using RATES 
and DARTS. Agreement has already been 
reached, in principle, that the ETMS will include 
the GTC in its architecture. 

Integrated Test Facility 

GPT Limited is developing an upgrade of the 
System X test network subsystem. This promises 
an improvement in the speed and availability of 
some tests. 

Expert Diagnosis 

Independent studies have been taking place on 
expert systems capable of diagnosing faults by 
applying complex algorithms to the results of line 
tests. Similarly, algorithms can be applied to learn 
from the experience of previous test results. 

The algorithms may in the near future be writ¬ 
ten into the test scripts and applied by the inter¬ 
pretation engines of GTCs. 

Applied in cooperation with spacial, temporal 
and logical correlation of network events by fault 
and repair management systems (FARMS) and 
efficient despatch of field personnel by force and 
work management systems (FAWMS) repair 
times will be decreased. 

Distributed Environment for Testing 
Communications Technology (DETECT) 

It is sometimes necessary to construct automated 
test environments capable of testing the com¬ 
munications service provided between geo¬ 
graphically separate points. An approach called 
DETECT has been developed within BT Devel¬ 
opment and Procurement to meet this need. DE¬ 
TECT technology is being exploited and 
enhanced to provide test services independent of 
the network under test. Some DETECT tech¬ 
niques will be exploited in the GTC work de¬ 
scribed earlier, to provide built-in network test 
facilities. 

Concert™ 

By using GTCs, it may be possible to offer net¬ 
work test service to customers. This includes: 

® customer initiated testing of BT’s network and 
services, and 

• siting GTCs on customer premises to facilitate 
testing at the critical boundary between customer 
premises equipment and licensed operator re¬ 
sponsibility. 

Test Control in New Hardware 
Technology 

Test protocols for integrated circuits are being 
developed. Each chip on a slide-in-card conforms 
to the protocol (IEEE 1149.1) and has pins con- 
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necting it to a common bus. An associated proto¬ 
col links the card on the back-plane to give remote 
test access into chip level functionality. 

It may be possible in future, providing the 
future holds a significant penetration of equip¬ 
ment supporting these protocols (and if the re¬ 
quirement to remotely test within a replaceable 
item is established), for the GTC to provide full 
exploitation of that capability. 

Portable Testers 

BT currently uses a multiplicity of portable tester 
types (about 100). Given the right test access, 
GTC could be used to offer those tests remotely. 
If just a small percentage of the use of these testers 
could be automated, significant savings should be 
possible. 

CONCLUSION 

TAMSES has identified a target architecture for 
network test management systems based on a 
distributed network of GTCs. 

Development of individual SSAs in isolation 
will accomplish limited advantage. Applied in 
cooperation with developments in fault and repair 
management systems, force and work manage¬ 
ment systems (FAWMS), and other systems in the 
Network Support Systems Architecture, signifi¬ 
cant improvements in the business processes 
using testing will be achieved. 
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National Charging Database 

S. SMYTON, and U. McMAHONt 


The accuracy and integrity of the call charging data used by BT’s exchanges are of paramount importance . 
This article outlines the history and development of the national charging database and describes the new 
tools now becoming available to audit the system. 


INTRODUCTION 

The national charging database (NCDB) has been 
developed to maintain one set of charging data 
which can be utilised by all BT exchanges and 
systems that need to price calls. It ensures that 
accurate call pricing information is available for 
charging telephone calls originating within the 
BT UK network. 

CARDVU (charging and routing data verifica¬ 
tion utility) is an automatic auditing tool, de¬ 
signed to give a network-wide summary of 
charging errors. 

Using the data available within NCDB, 
CARDVU reinforces BT’s ability to demonstrate 
adherence to the OFTEL (Office of Telecom¬ 
munications) requirement that all possible 
measures are being taken to ensure that customers 
are charged accurately. 

Prior to the introduction of NCDB in 1989, all 
tariff revisions were carried out manually. Appro¬ 
val for the project was granted in 1988. The first 
version went live in February 1989, and the Lon¬ 
don code change release went live in October 
1989. 

The objectives of NCDB are to: 

• hold all charging and tariff data for BT World¬ 
wide Networks call pricing systems, 

O provide, wherever possible, an electronic 
transfer of data to the systems which price cus¬ 
tomer calls, 

• provide data to enable monthly audit of pricing 
systems, 

• update directly, pricing data on all call pricing 
systems, 

® hold full national numbering data, and 

• cope with rapidly changing network and busi¬ 
ness requirements. 

Call Pricing 

Before a call can be priced the following informa¬ 
tion is required: 

• type of calling customer 

• location of calling customer 
& the digits dialled 

© the time of day 
® the day of the week 

• the duration of the call. 


t BT Development and Procurement 


The NCDB holds this information in the follow¬ 
ing form: 

(a) Charge Group Each customer belongs 
to a single charge group. A charge group covers 
an area of the UK and is normally made up of 
several exchanges. There are currently 634 
charge groups in the UK. 

(b) Charge Band This is determined by the 
origin and the destination of the call. Normally 
this is related to the distance between them, but 
the charge band can be the same over the whole 
country, regardless of distance; for example, Call- 
Stream Service. 

(c) Tariff Group Each customer is allocated 
to a tariff group. Although the NCDB does not 
maintain individual customer groupings, it has 
sufficient data to price a call. 

(d) Tariff Data This is used to determine the 
time allowed for an individual call. Tariff data 
includes the charge rate (peak, standard or cheap), 
and the day type (weekday, weekend or conces¬ 
sionary) for each tariff group. 

The NCDB, therefore, holds charge-band 
information for each charge group to each desti¬ 
nation, as well as all-number strings to identify 
uniquely the charge group in which every range 
of numbers, and thus each customer, is located. 

By using the digits dialled by the customer (the 
charging number string), the NCDB calculates 
precisely the cost of a call made by any BT 
customer. 

The ability within NCDB to update, insert and 
delete charge bands, charge groups, tariff rates, 
exchanges, etc., allows any alterations that are 
made to the telecommunications system to be 
incorporated easily into NCDB. 

Structure 

The NCDB system consists of five completely 
separate databases: 

(a) Present 

( b ) Partial 

(c) Future 

(d) Workl 

(e) Work2 

Each of these databases has an identical set of 
tables, although the actual data stored within the 
same table across the databases may differ. 
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Figure 1 

System 

configuration 


The system has been developed to run on a 
standalone computer and also as a product within 
the digital exchange support system (DESS) clus¬ 
ter. The standalone system runs all five NCDB 
databases, while the DESS cluster runs only the 
Present and Future databases, which are held as 
read-only files, thus preventing uncontrolled 
changes to those databases. These provide access 
to the current charging data and to data that will 
introduce the next tariff change, see Figure 1. 




USERS 


The standalone computer is located within a 
secure environment and only encrypted links are 
available for access by Network Pricing and 
NCDB Data Collection Input (NDCI) users. The 
two work databases are held on the standalone 
computer and these are used for modelling and 
manipulation of the charging/tariff data. The 
Workl database is used mainly for the production 
of tariff revisions and the Work2 database for 
studies of pricing structures. 

CHARGING AND ROUTING DATA 
VERIFICATION UTILITY (CARDVU) 

The method of carrying out data auditing at the 
moment is for NCDB to produce reports known 
as Mil files. Each file represents one of the 634 
charge groups within the BT network, and con¬ 
tains details of the charge number strings that are 
available to customers in that charge area, 
together with their associated charge band. 

NCDB also produces a monthly set of standard 
files containing charging data which apply across 


all exchanges in the network; that is, duration per 
unit fee depending on day and time, etc. These 
files are provided to the district data managers as 
input for the AUDAX and TXE4ECAT audit 
tools. 

Each month, the data on every digital ex¬ 
change is archived and this data is used, with the 
appropriate audit tool, to compare the exchange 
charging data with the Mil and standard files, 
provided by NCDB. Reports, which contain er¬ 
rors and warnings, are produced for district data 
managers. 

This error-checking process has some prob¬ 
lems, not least of which is the data being up to a 
month out of date. Some of the enhancements 
planned for NCDB are aimed at keeping these 
files in step with the NCDB database. 

When CARDVU Version 1.1 is operational in 
early-1992, charging data for each TXE4E ex¬ 
change will be manually transferred each month 
(by district data managers using a file transfer 
utility) to the DESS environment. 

CARDVU will then automatically audit that 
data against data supplied by NCDB (see 
Figure 2 for overview). 



Figure 2—Overview of NCDB and CARDVU 


The outline plan is to have similar facilities 
available for System X and AXE10 during 1992. 
System X data will then be transferred to DESS. 

The AXE10 charging data will be automat¬ 
ically retrieved by CARDVU following an elec¬ 
tronic request to the relevant district data collector 
(DDC). The DDC will retrieve the data from the 
exchange and transmit it to CARDVU by using 
the file transfer access and management (FTAM) 
protocol. 

In the longer term, System X exchange data 
may also be retrieved automatically, though this 
may depend on the provision of new remote 
archive load facility (RALF) units at all 
System X processors. RALF would provide an 
electronic link between DESS and the System X 
exchanges, and CARDVU could then automat¬ 
ically request the data it requires. Alternatively, 
data collection may be possible via the DDC. 
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The following functions will be available to 
CARDVU users: 

(a) Scheduling 

© Schedule audits for all exchanges on the net¬ 
work. An audit must be scheduled (for a specific 
date and time) for every exchange at least once 
per month. Additional audits may be scheduled; 
for example, to check the effect of changes made 
to the exchange data, due to a tariff revision. 

© Change any audit schedule date. 

(b) Auditing 

® If an AXE10 exchange is being audited, then 
CARDVU will launch a job on the relevant DDC 
and then wait for it to return the required data. 
CARDVU will expect System X and TXE4E data 
to have been transferred to DESS before the sche¬ 
duled audit time. 

® CARDVU will compare the exchange data 
against the NCDB data, log all errors/wamings in 
a database and inform district staff (by electronic 
mail) that there are errors to be dealt with. 

# CARDVU will maintain a file of the status of 
all audits, and the result, for example, pending, 
executing, completed or failed, so that it can 
report on them. 

0 CARDVU will automatically clear errors 
found in a previous audit if they do not recur. 

(c) Commenting 

0 CARDVU will allow users to comment on 
errors logged against an exchange. 

0 Comments can be added by more than one 
user. 

^ Errors can be noted as CLEARED. 

(i d) Reporting 

# CARDVU will generate exchange specific, 
network operations unit (NOU)-wide or network¬ 
wide audit reports. 

# Reports can be produced on the status of ex¬ 
change audits for the current month; for example, 
number of exchanges audited, not audited, etc. 

(e) Escalating 

Q If errors logged by a CARDVU audit are not 
commented on within a defined time period, 
CARDVU will escalate them to district security 
officers and will continue to do so until they are 
acknowledged. This escalation will be handled by 
electronic mail or by Radiopaging. 

Once BT network management teams have 
access to the full CARDVU system, they should 
start to see the following benefits: 

# Available resource will have more time to 
perform higher level functions with the elimina¬ 
tion of most of the manual activity. 

# More reliable information will be available to 
higher management on the accuracy of customer 
charging nationwide. 

# Trends will be identified which should lead to 
improved network operation. 


There will remain some manual tasks, that is, 
copying exchange data to DESS, but these may 
also be overcome in the longer term, thus increas¬ 
ing the above benefits. 

Figure 3 shows the links between NCDB and 
CARDVU, and other systems. 



Figure 3 
Links between 
NCDB, CARDVU 
and other systems 


Implementation 

NCDB is a fourth-generation software product 
developed using the ORACLE relational data¬ 
base management system. 

CARDVU has been developed also by using 
the ORACLE relational database management 
system. 

The first release of CARDVU is planned for 
early-1992 and will provide facilities for the auto¬ 
matic auditing of TXE4E exchange data. Future 
releases will provide similar facilities for 
System X and AXE 10 exchanges. 

Until CARDVU goes on-line, the following 
systems will continue to be used to audit ex¬ 
change data. For System X exchanges, there is the 
CATMAC (Charging Accuracy Team MACro) 
product. This was originally a personal computer 
based tool that has subsequently been ported to 
the DESS VAX cluster. 

AXE10 exchanges are audited by using 
AUDAX (AUDit AXelO), which is also a per¬ 
sonal computer-based product. 

For TXE4E exchanges, there is the TXE4CAT 
product which provides an audit facility for 
TXE4E exchange charging data. 

There are a number of problems associated 
with the existing auditing tools, CATMAC, 
AUDAX, TXE4ECAT. In summary, they include: 

(a) lack of control over their use; for example, 
there are no facilities to ensure that: 

C audits are carried out on a regular monthly 
basis, 

• any errors identified in the audit are corrected, 
and 

• there was no manual intervention and that data 
was not modified before an audit took place; 
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(b) lack of a network-wide picture of the ac¬ 
curacy of exchange charging data; 

(c) the manual creation of control files, and 
transfer of data to a personal computer; and 

(< d) generation of spurious errors due to report 
(Mil) files being out of date. 

CARDVU will resolve the above problems 
and will provide some facilities/features, which 
currently do not exist. 

Responsibility for operation of the NCDB is 
shared between the Network Pricing Division 
and the NDCI group. The NDCI is responsible 
for incorporating number changes, provided by 
districts, into NCDB. The Pricing Division is 
responsible for all other data held in the data¬ 
bases. Supervision of the NCDB is the respon¬ 
sibility of the network pricing database 
administrator. 

Future 

During the next year, new releases of CARDVU 
will provide the following functionality: 

© automatic access of TXE4E data via the DDC, 
0 assessment of financial loss/gain associated 
with all reported errors, 

# audit of System X data, 

© audit of AXE 10 data, and 

© audit of Operator Service System (OSS) data. 

In the longer term, enhancements may be re¬ 
quired to: 

© audit new types of charging data, 

© audit new types of non-charging data, and 

# provide for automatic access to System X data. 

Most of the above CARDVU enhancements 
will require enhancements to NCDB to enable it 
to provide the required reference data. 

CONCLUSION 

The NCDB is the single reference source of net¬ 
work charging and tariff data for use within BT. 


The integration of BT’s network support sys¬ 
tems is a prime aim of the Network Administra¬ 
tion Implementation Programme. This 
integration should be achieved by using Open 
Systems Interconnection standards; such as Co¬ 
operative Network Architecture-Management. 
An example of this is the FTAM link between 
DESS and the DDCs, which CARDVU uses to 
extract AXE 10 and TXE4E charging data. 

The role of NCDB and CARDVU is vital as 
the base for accurate call charging. As flexible 
pricing becomes a feature of the services offered 
by the network, call charging databases and the 
verification of call charging will be an important 
aspect of ensuring customer satisfaction. 
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Network Hamagemen! Workstation 

A. D. VICKERS and V. TRAYNORt 


Computer access in BT is undergoing a transformation. The traditional image of one user, one system, 
one terminal is changing to one where users are increasingly being required to access a number of 
disparate computer systems to perform a complex range of tasks. The network management workstation 
(NMW2) is playing a major role in the realisation of this scenario. This article explains how the NMW2 
achieves terminal and system integration, its requirements and functionality are described and some 
future aspects are discussed. 


INTRODUCTION 

The network management workstation (NMW2) 
offers end-users a secure and controlled window¬ 
ing workstation environment from which they 
can access a number of host systems simulta¬ 
neously. It has been developed by the Network 
Management Department to facilitate front-end 
integration of disparate key systems and to pro¬ 
vide a platform for a more sophisticated human- 
computer interface. 

HUMAN-COMPUTER INTERACTION 

The following section discusses conventional 
system access in BT. It is followed by an examin¬ 
ation of how the NMW2 overcomes the two major 
problems of computer access, namely, the inte¬ 
gration of terminals and systems. 

Conventional System Access 

Up to the late-1980s, computerisation of network 
administration concentrated on improving and 
automating single tasks in an uncoordinated 
fashion using systems developed by specific manu¬ 
facturers, each with its own user interface and 
terminal type. The rationalisation of network ad¬ 
ministration being undertaken by the Network Ad¬ 
ministration Implementation Programme (NAIP) 
has resulted in network operators requiring access 
to a number of systems to undertake their work. As 
a result, more and more personnel are required to 
operate disparate computer systems, negotiate their 
unique documentation, and learn entirely new user 
interfaces. The problem is illustrated in Figure 1. 

This situation is becoming more prevalent as 
the network and its management are being mod¬ 
ernised and where users perform fewer system- 
specific duties such as surveillance of the trunk 
transmission network, but instead work in func¬ 
tional areas (such as fault management), or sup¬ 
port a business process (such as technical front 
office functions or end-to-end circuit provision). 

Each individual host system is only con¬ 
cerned about its own security so that users must 
log on to each terminal with their username, 
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Figure 1 
Conventional 
system access 


password and swipe card, if required. This pro¬ 
cess is laborious when accessing more than one 
system such that users may be tempted to dupli¬ 
cate or document their numerous passwords 
which violates security procedures and jeopard¬ 
ises system security. 

There is neither terminal nor system integra¬ 
tion in the above scenario, operators essentially 
running each system’s terminal in parallel, with 
the inter-system communications only performed 
through manual keyboard re-entry. Here the user 
is the integrator. 

The NMW2 is a means of overcoming these 
shortcomings by facilitating terminal and system 
integration. As these solutions vary quite consid¬ 
erably in complexity, the NMW2 provides a 
smooth migration pathway from one to the other. 

Multiple Terminal Integration 

The first phase, which has proven successful at 
operational sites, is to provide terminal integra¬ 
tion. Here the NMW2 has the facility to access a 
number of specific hosts, as individual windows, 
through a single workstation as if the system-spe¬ 
cific terminals were hidden behind the worksta¬ 
tion screen. This is illustrated in Figure 2. 

NMW2 will be used to access all BT’s major 
host systems. It is currently being validated for 
IBM, Digital and ICL sessions over the INTER¬ 
NET network and some non-INTERNET hosts 
such as MS-DOS systems. Access to Hewlett 
Packard systems over INTERNET will be vali¬ 
dated shortly. 
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Figure 2 
Terminal 
integration 



Thus, for example, operators can now access the 
operations and maintenance centre (OMC), and 
Customer Service System (CSS) simultaneously 
through one terminal. The system interaction is still 
by manual keyboard re-entry but, because it now 
takes place on a single screen with a modem user- 
friendly environment instead of a single text-based 
terminal, a number of benefits arise. Users learn 
how to operate graphical workstations quicker than 
a number of disparate computers, they experience 
reduced frustration and fatigue and, as a result, the 
quality of their work improves. Specifically, users 
complete more tasks with less errors than they 
would otherwise perform. 

The NMW2 incorporates a mechanism which 
provides one of the highest levels of access se¬ 
curity currently in use within BT. The intelligent 
smart card provides the facility for users to log on 
to all of their systems via a single secure point of 
access. They need only enter a single username, 
password and a ‘onetime passnumber’ which can 
uniquely identify users and their smart cards to 
the NMW2. After successful log-in, the NMW2 
is tailored with each user’s profile detailing the 
hosts to which they are permitted access. No 
further log-on is therefore required, users entering 
required hosts as necessary. 

Figure 3 Although it is now proven to be technically 

INTERNET LAN possible for a secure NMW2 automatically to log 



users on to host systems, BT’s current security 
policy requires that they still log on to each host 
system individually. Investigations are underway 
to amend this approach. 

The network management workstation has a 
number of facilities allowing controlled copy and 
paste between secure applications. The first per¬ 
mits the straight transfer of data to and from host 
systems. Facilities via the Ml779 terminal emu¬ 
lation selection manager can identify predeter¬ 
mined strings of data and interpret and enter them 
on host system screens. For example, ‘Control A’ 
would be entered as ‘ A A’. A selective copy and 
paste is also planned which will only copy certain 
fields. Text can be stored temporarily in a clip¬ 
board for frequent use. 

The copy and paste facilities described above 
will improve the accuracy of users’ transactions 
and will save time. 

There are two variants of NMW2 terminal 
integration depending on the type of the local area 
network (LAN) on site: 

# INTERNET system access, and 
0 non-INTERNET system access. 

These are described below. 

INTERNET System Access 

INTERNET is BT’s internal networking strategy 
to provide authorised access to various applications 
running on a variety of vendors’ hosts. It employs 
the T-NET Plus LAN which is presently accessed 
by means of a dumb text-based terminal, the 
M1779. This was developed for BT in 1986 to gain 
multiple concurrent system access and to look and 
behave like a native terminal. The M1779 is essen¬ 
tially a Digital VT220-like terminal with extra 
features to support IBM, Hewlett Packard and cer¬ 
tain other terminal types, and therefore reduces the 
number of terminals required at INTERNET sites. 

The M1779 performs well in most scenarios, 
but for applications where simultaneous access to 
multiple systems is required, it is deficient. It can 
support multiple host links, only one of which can 
be active at any one time. Furthermore, neither 
data nor files can be transferred between sessions 
and, because it has no local processing power, it 
cannot display modern graphical user interfaces. 
These weaknesses are addressed by the NMW2. 

To appreciate how the NMW2 operates in the 
INTERNET environment, it is necessary to under¬ 
stand how the Ml779 terminals work. This is be¬ 
cause, to conform with INTERNET procedures, 
the INTERNET NMW2 must behave like a num¬ 
ber of M1779 terminals. As will be seen, the IN¬ 
TERNET architecture is not rigid and will be 
migrating towards open standards. The following 
sections explain how the NMW2 will operate in 
these scenarios. 

Current INTERNET Architecture 

Figure 3 illustrates an INTERNET NMW2 and 
two Ml779 terminals co-residing on the current 
T-NET Plus LAN. 
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M1779 terminals are physically connected 
using Digital terminal servers to the T-NET Plus 
Ethernet. When powered up, both terminals and 
terminal servers connect to which ever network 
access module (NAM) is least loaded. The soft¬ 
ware on that NAM validates the user access and 
presents the user with a menu of hosts to which 
the user is permitted access. Once a host is 
chosen, the NAM provides emulations and gate¬ 
ways, if required, forges the M1779-to-host link 
and implements system security. The allocation 
of resources is managed by the network manage¬ 
ment control centre, (NMCC). 

The NMW2 gains access to the INTERNET 
by emulating, in software, Ml779 terminals and 
their multi-port terminal server. It runs the 
multiple emulations through the NAM with the 
NMCC carrying out its role as normal. Each time 
users request access to host systems, the NMW2 
fires up another Ml779 emulation and simulta¬ 
neous system access is attained. Emulations are 
provided by means of an Ml779 terminal emula¬ 
tor which has recently been validated and ap¬ 
proved as part of the INTERNET portfolio for 
connection to T-NET Plus. 

Figure 4 illustrates the Ml779 emulation ac¬ 
cessing two CSS sessions. 

Future INTERNET Architecture 

As the NMW2 is the INTERNET portfolio 
UNIX workstation, it will continue to be com¬ 
patible with future INTERNET architectures. It 
is initially planned to migrate the largely pro¬ 
prietary NAM architecture towards an open 
architecture. It is likely that the Ml779 termi¬ 
nals, NAM and NMCC will be replaced by a 
workstation, (providing full, direct terminal 
emulations) and additional equipment to replace 
the NAM and NMCC. 

The advantages of the open architecture in¬ 
clude: cost reductions (NAMs will not be needed, 
their replacements will be fewer in numbers and 
will be purchased in the competitive open mar¬ 
ket); improved performance (since the worksta¬ 
tion will be directly connected to the network); 
reduced network traffic, and the ability for local 
processing. 

Non-INTERNET System Access 

The non-INTERNET system access is illustrated 
in Figure 5. Here the NMW2 sits on the Ethernet 
LAN and accesses host systems using the necess¬ 
ary terminal emulators and gateways. Non-IN¬ 
TERNET installations are a combination of 
procured emulators (for example, IBM) and inter¬ 
nal BT emulators such as the M1779. 

This type of NMW2 configuration has been 
successfully installed at BT’s Madley Communi¬ 
cations Centre, Hereford. 

The previous sections explain how the NMW2 
is being employed to integrate terminals in both 
INTERNET and non-INTERNET environments. 



It is a ‘super terminal’ for use by personnel who Figure 4 
are regularly required to gain simultaneous access NMW2’s M1779 
to, and transfer data between, a number of sys- emulation 
terns. It will, therefore, not be replacing all of 
BT’s dumb terminals. Ml779s, personal compu¬ 
ters, Digital VTlOOs and such like will remain in 
operation for users who do not need its sophisti¬ 
cated interface or in areas which will not be 
migrating towards a distributed processing envi¬ 
ronment. 



Figure 5 

Non-INTERNET 
system access 


System Integration 

The preceding sections have dealt with the inte¬ 
gration of terminals onto a single NMW2 work¬ 
station. This will greatly enhance the 
human-computer interface in that it will reduce 
the numbers of terminals and improve productiv¬ 
ity through copy and paste facilities and such like. 
However, it still requires users to understand each 
host system, their interfaces and documentation. 
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It is possible to integrate host systems to com¬ 
municate at a process-to-process level with users 
having a more applicable, single-user interface 
based on the NMW2. This is illustrated in 
Figure 6. 

In this instance, systems will request, receive 
and send data to each other over Open Systems 
Interconnection (OSI) networks without the need 
for user intervention. This communication will 
still be under the control of the user and, because 
the NMW2 supports complex graphical displays, 
it can be represented by using screens which are 
custom designed for that specific duty. These can 
contain higher densities of information in a for¬ 
mat which is easier to assimilate than multiple 
screens of text. 

Applications are being developed, using the 
Cooperative Networking Architecture (CNA) 
compliant BTXT toolkit, to carry out this process- 
to-process communication. Examples include the 
problem manager workstation, which will pro¬ 
vide a generic fault management facility, and the 
customer network complaints analysis system. 
Both of these illustrate how large applications can 
be integrated with the common NMW2 infra¬ 
structure. 

The NMW2 can provide a migration path from 
the above terminal integration to this system in¬ 
tegration because it has been built on an open 
platform and it can provide the necessary dis¬ 
tributed processing. 

KEY REQUIREMENTS 

The key requirements for the network manage¬ 
ment workstation arose out of analysis by the 
Network Control Architecture Board (NCAB), 
NAIP, the INTERNET Workstation Committee 
Requirements Capture Exercise and other net¬ 
work administration projects. 

These requirements are described below. 


Improve and Rationalise BT System 
Access 

The improvement to system access has been de¬ 
scribed in the previous sections. 

BT aims to evolve over 200 current systems to 
around 40 fully-integrated high-functionality key 
systems. User access to these systems must be 
rationalised so that users experience a consistent 
user interface, products for internal and external 
use have a common style and, most importantly, 
no duplication of graphical user interface devel¬ 
opment occurs. 

Now that the NMW2 is the INTERNET Com¬ 
mittee’s recommended Unix workstation and the 
NCAB standard graphical user interface, it is 
intended that this will assist in its rationalisation. 

Standards Conformance 

To ensure BT has a truly portable graphical work¬ 
station and to exploit the price competitiveness of 
that open market, the NMW2 has been developed 
using the following standards: 

<B Operating System: UNIX (POSIX 1003.1) 

# Protocol: X Window System ANSI X3H3.6 
O Graphical Toolkit: BTXT (BT’s CNA User 
Interface compliant toolkit) 

Q X Window System Applications conformant 
to the Inter Client Communications Conventions 
Manual (ICCCM) 

The NMW2 and BTXT were developed in 
conjunction with the authors of BT’s Cooperative 
Networking Architecture User Interface Style 
Guide and therefore conformance to that guide is 
eased. 

Protect Current Investments 

It is important that new technology does not ren¬ 
der existing hardware and software worthless, but 
instead protects that investment where possible. 
Thus, for example, the development of NMW2’s 
M1779 emulator, although obviating the need for 
some Ml779 terminals, still makes full use of the 
NAM and NMCC. The latter will eventually be 
replaced with cheaper, open systems equipment. 

Generic NMW2 Development 

The NMW2 provides a software environment 
onto which new value-added services can be 
added via a smooth migration. Its open platform 
is modular, flexible and extensible, permitting 
each new installation to be essentially custom 
built with the core NMW2 software and the 
necessary ‘bolt-on’ components, such as specific 
terminal emulators or network management ap¬ 
plications. 

It will also be possible to retrofit new software 
modules (such as the electronic documentation 
retrieval system (EDRS)) to existing configura¬ 
tions. 

The generic nature of the NMW2 raises a 
number of opportunities which, surprisingly, 
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have more bearing on product coordination and 
build control than technological capability. 

Ergonomic and Graphical User Interface 

The NMW2 has been developed principally to 
provide terminal and system integration for end- 
users. It has the further role of providing a graphi¬ 
cal user interface subsystem environment onto 
which BT and external applications may be de¬ 
veloped. It poses no unfair restrictions on them 
except that they must be ‘well-behaved’ and do 
not compromise any other applications running 
on the NMW2. 

BT’s X Toolkit (BTXT) provides the key be¬ 
tween the interworking of NMW2 and other ap¬ 
plications. It is based on a widely used toolkit, 
Interviews, which has been in existence for many 
years as part of the standard X release. It is 
complemented with proprietary higher function¬ 
ality. It consists of a library of graphical and user 
interface tools which application developers may 
employ to construct the user interface. In addition 
to improving the efficiency of user interface de¬ 
velopment (because such tools construct the in¬ 
terface much quicker than starting from basics), 
the toolkit provides for a consistent ‘look and feel’ 
to all user interface products. Furthermore, it en¬ 
capsulates BT’s new corporate identity. 

BT may move to industry’s eventual choice of 
standard graphical user interface, for example, 
Motif or OpenLook. It will, however, retain the 
option to remain with BTXT if this proves advant¬ 
ageous. 
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BT Display Manager 

The BT display manager (BTDM) is the applica¬ 
tion which validates the user for access to the 
system and starts the session manager. It makes 
use of the smart card security system. 

BTDM is a modified version of the XI1 Re¬ 
lease 4 application XDM. 


Figure 7 
NMW2 user 
interface 


BT Session Manager 


NMW2 FUNCTIONALITY 

The NMW2 utilises a friendly WIMP (windows, 
icons, mouse and pointer) user interface compris¬ 
ing a set of standard X Windows manager clients 
(the session manager, window manager, display 
manager and colour manager) and a range of office 
automation application clients. It is illustrated in 
Figure 7. Users interact with the system by a com¬ 
bination of moving the mouse pointer around the 
display, clicking mouse buttons and typing charac¬ 
ters on the keyboard. General and context-sensitive 
help is available at all times. 

Once log-in is successful, users are presented 
with a session manager window which lists those 
tools to which the user has been given access and 
those which have been invoked. Providing the 
necessary communication links are intact, in¬ 
voked tools appear on the workstation screen as 
a window. Hosts will run simultaneously on the 
NMW2: users may move from one window to 
another as necessary. 

The NMW2 provides users with an environ¬ 
ment shielded from the complexities of system 
invocation and where they are prohibited from 
accessing the UNIX operating system. Each in¬ 
stallation has a system administrator with a var¬ 
iety of NMW2 administration tools to assist in its 
management. 

The NMW2 functionality is summarised below. 


The BT session manager (BTSM) controls user 
access to all NMW2 applications. Its functions 
include the following: 

O display session window using the user’s 
profile to tailor the available tools menu 
0 start and stop applications 
Q log significant events and failures 
© configuration of workstation characteristics 
and printer configurations. 

The session manager is shown in Figure 8. 

BT Window Manager 

The BT window manager (BTWM) manages the 
NMW2 display. It processes and mediates re¬ 
quests from the user and software to manipulate 
windows and the NMW2 display. This includes: 
re-sizing, iconifying and printing the window. 

It is based on the XI1 Release 4 standard 
window manager (TWM), configured to be CNA 
User Interface Style Guide compliant*)! 

NMW2 System Administration 

The NMW2 system administration facility has 
been developed for users with relatively little 


t Cooperative Networking Architecture User Inter¬ 
face Style Guide, Look and Feel. RD00024. 
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NMW2 session UNIX system management experience. It pro- 

manager vides the following functions: user configuration 

(for example, to add a new user to the system); 
tool control (for example, to load applications 
from magnetic tape); network control (for 
example, to maintain the network hardware); and 
an audit interrogator (for analysing major events). 

Desktop Tools 

Typical desktop tools provided with the NMW2 
include: analogue and digital clocks, hexadeci¬ 
mal calculator, calendar, conference (broadcast) 
facility, mail and post-it notes. 

These are taken from the standard X. 11 Re¬ 
lease 4 configured to integrate with the NMW2 
environment. 

NMW2 CONFIGURATIONS 

The workstation-based NMW2 architecture sup¬ 
ports a variety of configurations. It may simply be 
a standalone system linking into a number of 
hosts via dedicated lines or over an Ethernet LAN. 
Installations requiring more workstations may 
choose to utilise a server to offload processing 
from the workstations and improve performance. 
The NMW2 supports resilience and performance 


techniques such as disc stand-by and dual LAN 
configurations. 

NMW2 FUTURES 

Developments are currently underway to improve 
the mechanism of multiple terminal integration. 
As has been described, this will aim to provide 
full intelligent copy and paste facilities together 
with the integration of all key host systems. Sys¬ 
tem integration will be provided through projects 
including PMW and CNCAS. 

Furthermore, applications are being developed 
to ease the automation of repetitive tasks which 
users are required to perform. 

The NMW2 will have a significant roll-out 
into BT’s operational sites for those users who 
require a sophisticated integrating terminal: it 
will not be replacing all of BT’s terminals. 

Although developed for network management 
applications, the NMW2 could also be used to 
access a variety of non-network management sce¬ 
narios which need multiple, simultaneous system 
access. 

CONCLUSIONS 

Efficient computer access in BT requires the in¬ 
tegration of host terminals followed by the inter- 
connection of host systems in an open 
environment. The NMW2 provides a platform to 
facilitate this migration. It is a powerful window¬ 
ing workstation giving simultaneous system ac¬ 
cess together with a platform for more 
sophisticated human-computer interaction. 
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Electronic Document Retrieval System 

B. A. CLAYDONt 


A feasibility study is being carried out into providing an electronic document retrieval system for 
operations and maintenance staff to replace the numerous forms of paper documents currently used. This 
article examines the problems caused by the present documentation system , describes the technologies 
that could be used and outlines how the new system might be provided. 


INTRODUCTION 

A feasibility study into providing BT’s network 
management staff with an electronic document 
delivery, storage and retrieval system, called the 
electronic document retrieval system (EDRS), is 
currently being undertaken. It will look into pro¬ 
viding the enabling technology to ensure that 
information is produced reliably, and delivered to 
the right place, to the right person, at the right time 
and in the right format. 

A list of the potential benefits that the proposed 
system is expected to deliver is given below: 

Direct 

Q Reduced storage requirements. 

© Up-to-date information always available. 

© Reduced search time. 

Q Reduced filing time. 

# Reduced travelling time. 

Q Reduced transportation and postage costs. 

© Full availability of information to all staff who 
are permitted access. 

O Reduced furniture requirements allowing 
more staff to be accommodated in existing floor 
space. 

# Reduced paper and photocopying costs. 

# Reduced operational costs. 

Indirect 

O Reduced errors due to the availability of up-to- 
date information. 

# Improved working integrity. 

© Improved image to BT. 

© Reduced network down time. 

# Fast global updates. 

# Confidence in latest information. 

© Less clutter on desks. 

# Faster restoration of service/facilities to custo¬ 
mers. 

© ‘Green’image! 

THE PROBLEM 

The project is addressing the problem of mana¬ 
ging the technical documentation used by BT’s 
network operations and maintenance staff. This 
technical documentation includes, for example, 
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the operations and maintenance (O&M) manuals 
associated with telephone exchanges, and other 
related documents produced within the company. 
These documents are delivered from many sour¬ 
ces. Furthermore, documents are published by 
several internal sources to modify the usage of, or 
correct the information in, the original docu¬ 
ments. 

Consequently, many forms of documentation 
are currently being delivered on paper, in many 
formats, to the end-user. This and the subsequent 
upgrades present numerous delivery, storage, con¬ 
figuration management and release control prob¬ 
lems, which every organisation needs to master. 

Operations and maintenance staff are being 
retrained from single-skilled on-site operations to 
multi-skilled remote and on-site operations. Pro¬ 
duct life cycles are reducing as a result of the pace 
of change. These factors are causing an ever-in¬ 
creasing flow of new documentation. Centralisa¬ 
tion of operations requires staff to have a general 
understanding of equipment and procedures and 
to refer to documentation for detail. Staff are 
therefore exposed to more, rather than less, do¬ 
cumentation. 

Supply 

Document suppliers use word-processing pack¬ 
ages to prepare each document, and then print it 
on paper to deliver it. Some external companies 
provide manuals on optical disc; this reduces the 
problems associated with the paper system, but 
still leaves a distribution and up-date problem. 
Even when documents are electronically de¬ 
livered, these may not be in the required format 
and normally necessitate specialised equipment, 
which does not provide a common delivery and 
retrieval system. 

There is no standardisation of document for¬ 
mats, delivery mechanisms, or release and con¬ 
figuration control across documents. The system 
is paper based, which limits the control and moni¬ 
toring of distribution, and the collection of user 
feedback. 

Additional Paperwork 

Most documents are updated after they have been 
distributed by attaching errata and addenda to the 
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originals. Staff raise additional notes and proce¬ 
dures related to a document. These need to be 
attached to the original, as margin or foot notes, 
or linked information. 

Distribution 

Multiple distribution points are used, some of 
which are in external companies, others in the 
various internal divisions of the company. A ma¬ 
nual distribution method ships large volumes of 
paper about the company to the remote sites. 
Updating the document usually means inserting 
update sheets into the originals, which may be 
located at thousands of sites. There is no guaran¬ 
tee that the updates are inserted and therefore 
used. 

Access 

Arrangements for access to the paper documents 
are currently very varied. Some staff have access 
to local centrally-managed libraries, whereas 
others carry their own version of the document set 
with them; for example, in their work van. 

To meet ISO9001 quality standards, staff need 
access to accurate and up-to-date documents. It 
has proven to be possible to keep only local 
centrally-managed libraries in an accurate and 
up-to-date state, although the mobile and office- 
based staff also have to meet this quality standard. 

The issue of ergonomics of access also needs 
to be addressed. Many staff complete their acti¬ 
vities by using a terminal remotely connected to 
the exchange equipment, or a mobile hand-held 
terminal, but they still have to follow paper-based 
standard procedures. They are less likely to use a 
document if they do not have ready access to it. 

LESSONS LEARNT TO DATE 
Prototypes 

During this project’s research phase, a number of 
approaches to elements of the problem have been 
tried: 

€> Optical character readers (OCRs) for non¬ 
electronic document input. A paper document is 
scanned with an OCR machine and converted into 
electronic form. 

O Generation of mark-upt from raw source files. 
A computer program is used to parse the docu¬ 
ment for its structure. A user can then use that 
structure to access the document. 

• Interconnecting an information system with 
another application. This demonstrates how an 
O&M system user could be provided with context 
sensitive access to System X documentation. 


t Mark-up provides ‘value added’ service for docu¬ 
ments. In its simplest form, it is identifying that a 
heading should be underlined. More complex forms 
provide facilities for defining the complete structure of 
a document prior to it being written. This document 
template can then be used to ‘drive’ a word processor 
so that the author has to comply with the structure. 


© Iconic representation of a document’s struc¬ 
ture. This provides user access to the documenta¬ 
tion via the graphical representation. 

® Hypertext. Various items in a document are 
interlinked so that a user can move directly to the 
page referred to in items like ‘see page 47’, ‘refer 
to diagram’, ‘complete procedure 29A/1 in vol¬ 
ume 7’. 

These ideas have been demonstrated on com¬ 
puter prototypes, in brief trials, which have used 
a range of technologies: personal computers, 
UNIX workstations, WIMPS interfaces, spe¬ 
cialised and general-purpose databases, stand¬ 
alone and integrated systems connected to 
operational systems. 

Conclusions 

© All the concepts are technically feasible. 

© Some of the concepts are expensive to imple¬ 
ment. 

© There are several solutions and component 
parts to an electronic document system. Techni¬ 
cally simple systems can yield business benefits 
and allow migration and change rather than rev¬ 
olution. 

© It is now time to deliver a basic system that 
supplies the essential 80% of the benefits, for 20% 
of the costs of development and deployment 
(Pareto’s 20/80 rule). 

THE WAY FORWARD 
Managing Change 

The proposed system will support the operational 
staff in managing the change from a paper system 
to an electronic one. It will support a logical 
incremental solution that delivers operational im¬ 
provements and business benefits in a controlled 
way. 

It will also assist the operational staff to man¬ 
age the information flowing to them. 

Infrastructure 

To achieve the desired business benefits, an elec¬ 
tronic document distribution system will be set 
up, as shown in Figure 1. It will consist of a central 
library that provides the interface between the 
document suppliers and the system. Branch 
libraries will provide end-users with access to the 
appropriate documents. 

This infrastructure will assist BT in estab¬ 
lishing standards related to document interchange 
and mark-up, and then in monitoring them. It will 
also provide more visibility and control of the 
process, thus making the problem more mana¬ 
geable. 

The network administration computer centres 
(NACCs), accessible over local and wide area net¬ 
works (INTERNET), will provide the technology 
backbone on which the system will be delivered. 

Staff will need retraining to work in the new 
libraries or to use the new system. However, if the 
new system appropriately models the existing 
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paper system then the retraining should be mini¬ 
mal. 

Controlled Supply 

Establishing standards, and getting them written 
into supply contracts, will be a high priority. 
Release control and audit trails will be im¬ 
plemented, to ensure document integrity. 

Documents will be validated against the stand¬ 
ard when received. A document’s usage and 
quality information will be fed back to the sup¬ 
plier, to ensure that documents are produced to an 
appropriate level of quality. 

Adding Value 

As mentioned earlier, many notes, procedures and 
links to other documents are produced to add 
value to an original document. A configuration- 
control problem therefore arises. Library man¬ 
agement facilities will be provided ‘to tie the 
paper-work together’ into a coherent set. 

Better monitoring and tuning of the business 
processes will be an additional spin-off from this 
coherent document set because the information 
can be logically linked together by using hyper¬ 
text concepts. Management staff can then thread 
standard practices and procedures through these 
documents, so that this mark-up directs the tech¬ 
nicians in their usage of the documents. Standard 
methods of working will then be easier to imple¬ 
ment, both nationally and locally, and can then be 
monitored and fine tuned. 

Access to Documents 

Documents will be accessed via a terminal or 
workstation, connected to the computer system, 
which holds the branch library. Access to the 
documents will be restricted by the normal se¬ 
curity mechanisms and by providing ‘views’ of 
the total library. 

Documents will be retrieved via a simple en¬ 
quiry mechanism by using the contents or index 
page models used in standard books, or complex 
enquiry mechanisms using keyword searching or 
hypertext models. Other network management 
support systems will give application-specific 
context-sensitive access to the documents. 

System Implementation 

This system is being implemented by using BT’s 
approved technology: UNIX computer systems, 
C/C ++ programs, ORACLE RDBMS, text termi¬ 
nals (Ml779), workstations (Network Manage¬ 
ment Workstation 2 (NMW2)), local and wide 
area networks (INTERNET). 

A client-server model is being used to allow for 
future client applications to use the library server 
services, as shown in Figure 1. Applications such 
as the operations and maintenance system (OMS) 
used to manage the exchanges, and the work man¬ 
agement system (WMS), will have client accounts 



with the system, to provide their users with context- 
sensitive access to the documents. 

This means that staff using these systems will 
have direct access to the documentation store, 
without having to leave their main application. 
The appropriate manual will open automatically 
at the page relevant to the current screen context. 


Figure 1 
Electronic 
information 
system—document 
delivery 


Feasibility Field Trials 


Feedback from network operations unit (NOU) 

and mobile staff will be used to add value to the 

statement of requirements, so that the requested Figure 2 

features can be built into the system at an appro- Electronic 

priate point in time. (See Figure 2.) information systems 
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EIS: Electronic information system 
NMW2: Network management workstation 
NOMS: Network operations and maintenance system 
OMS: Operations and maintenance system 
TNS: Transmission network surveillance 
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CONCLUSIONS 

Facilities that deliver high-priority business bene¬ 
fits, for the minimum cost, will be the first target 
of this project. Assisting the operational staff in 
managing the change from the current paper sys¬ 
tem to the electronic one will be a high priority. 
Better management of resources will be achieved 
by providing an incremental approach, based on 
cost-benefit evaluation. 

Although all the concepts are technically feas¬ 
ible, some will be implemented at a later date, 
when it is identified that they meet the business 
needs. 

The current feasibility study, sponsored by BT 
Worldwide Networks, is due to be completed by 
the end of the year. If the feasibility report is 
approved, a pilot system will be developed and 
deployed in 1992. 
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Network Management for RACE 

R. SMITH, and G. I. WILLIAMSON! 


This article introduces the work of a number of projects active in those parts of the European Community 
RACE (Research and Development for Advanced Communications in Europe) programme which address 
network management issues. The RACE programme is focused on pan-European integrated broadband 
communications (IBC) and aims to support the development of technology for the commercial introduc¬ 
tion of broadband services by 1995. IBC will integrate voice , data and video services over a single 
network. The article outlines three main themes: network management requirements of the integrated 
broadband communications network (IBCN); network management system specifications , architectures 
and reference configurations; and technology for network management systems , including applications 
and systems technology. 


INTRODUCTION 

At this point in time, the RACE (Research and 
Development for Advanced Communications in 
Europe) programme 1 comprises 80 or more pro¬ 
jects that address a broad spectrum of the issues 
which need to be resolved before cost-effective 
integrated broadband communications (IBC) ser¬ 
vices will be possible. These issues include: 

# definition of common functional specifica¬ 
tions and standards; 

O use of advanced technology for cost-effective 
implementation of IBC hardware and software; and 

# application pilot schemes where the validity of 
IBC service assumptions may be tested by service 
providers, network operators and end-users. 

Management of the IBC was recognised from 
the outset as an important issue for study in RACE 
and several projects were established to specify 
and develop the technology required. The inte¬ 
grated network management systems for IBC are 
referred to as the telecommunications manage¬ 
ment network (TMN). 

NETWORK MANAGEMENT IN RACE 

Six projects are currently active in the definition 
of network management for RACE. See Figure 1. 
Two of them are concerned with the specification 
of management aspects of the integrated broad¬ 
band communications network (IBCN): 

© the NETMAN project, which is concerned with 
producing the implementation-independent func¬ 
tional specification of network management for 
the IBCN; and 

# the TERRACE project, which is concerned 
with the definition of reference configurations 
and evolution scenarios for the introduction of 
IBCN management systems in Europe that are 
time and country dependent. 


t BT Development and Procurement 
This article is based on a paper presented at the IEE 
Broadband Conference. 


The remaining four projects, collectively 
known as the TMN technology projects , are 
charged with the task of developing and evalua¬ 
ting the enabling technology for implementation 
of network management systems for the IBCN. 

These are: 

• the AIM project, which is developing applica¬ 
tions of advanced information processing (AIP) 
techniques, mainly knowledge-based systems 
(KBS), for the maintenance of the EBCN; 

# the ADVANCE project, which is developing 
applications of AIP techniques, with an emphasis 
on advanced database and distribution tech¬ 
niques, for the network and customer administra¬ 
tion systems for the IBCN; 

Q the NEMESYS project, which is developing Figure 1 
applications of AIP techniques, for traffic and The TMN projects in 
quality-of-service (QOS) management of the RACE 



MAINTENANCE NETWORK AND TRAFFIC AND 

CUSTOMER QUALITY*0F-SERV1CE 
ADMINISTRATION MANAGEMENT 
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asynchronous transfer mode (ATM) switches in 
the IBCN; and 

© the GUIDELINE project, which provides a 
coordination framework for the RACE TMN 
work area in fields such as TMN architectures, 
standards, and technology assessment. 

The projects are staffed by workers from a 
wide range of organisations in Europe including 
public telecommunications operators (PTOs), 
equipment manufacturers, software houses and 
universities. BT has been involved in four of the 
projects since their inception in 1988. 

BT AND RACE TMN 

BT’s motivations for participation in RACE TMN 
are many. RACE is essentially a pre-competitive 
and pre-normative research and development 
programme. 

In general, the collaboration enables internal 
pragmatic and architectural developments and 
concepts to be extended by considering: broad¬ 
band; multi-service; many operators; and cross¬ 
country boundaries. 

This, combined with influence on interna¬ 
tional standards creation and the understanding of 
telecommunications cultures across Europe, are 
important facets in enabling BT to achieve its 
goals. The pre-normative aspects of RACE allow 
BT engineers to work with their counterparts in 
other PTOs and equipment manufacturers to vali¬ 
date architectural ideas important in the formula¬ 
tion of effective international standards. 

The pre-competitive technology assessments 
which RACE TMN is undertaking allow BT en¬ 
gineers to work with technology specialists from 
universities and software houses to understand 
the applicability of advanced information pro¬ 
cessing techniques to network management prob¬ 
lems. Studies focused on the management of the 
IBCN are providing useful insights into such re¬ 
quirements of future networks. 

Some of the technology results of RACE TMN 
are already being used in BT product develop¬ 
ments, and this will increase over the next year. 
BT people on the projects have worked closely 
with BT’s internal architectural activities (CNA- 
M) and a number of contributions to international 
standards have been adopted. 

MANAGEMENT REQUIREMENTS OF 
BROADBAND MULTI-SERVICE 
NETWORKS 

In this article, a very broad interpretation is taken 
of the term network management. Network man¬ 
agement activities are interpreted as being 
necessary to support all activities associated with 
the management of a telecommunications net¬ 
work. Such activities are being progressively 
automated, either to improve the efficiency of the 
network operators, or to allow the networks to 
provide new services. For this reason, network 
management systems cannot be divorced from 
the organisations which use them. Indeed, net¬ 


work management concerns the people within the 
organisation using tools to carry out procedures 
to manage telecommunication networks. The 
management activities, whether automatic or ma¬ 
nual, are intended to maintain the network at 
some operational optimum while minimising the 
resources required. 

Coherent classification schemes for ordering 
the network management activities help to struc¬ 
ture requirements. An approach to classification 
of requirements based on the life cycle of the 
network, as shown in Figure 2, gives an indica¬ 
tion of the scope of the requirements: 

® pre-service activities, which include planning, 
data building, installing and commissioning; 

<D in-service activities, which include mainten¬ 
ance, statistics, traffic management and billing; 
and 

O future service activities, which include perfor¬ 
mance analysis, forecasting and requirements 
identification. 



Figure 2—The life cycle model of network 
management activities 


It is clear that this is not the only means by 
which network management activities may be 
ordered. Another important issue is the time criti¬ 
cality of response required. For example, many 
activities such as forecasting and modelling of 
service demands are essentially off-line, whereas 
traffic management and maintenance require a 
real-time or near real-time response. Many other 
activities such as administration require some 
intermediate response time to support their inter¬ 
action with network elements. 

For the IBC multi-service networks, special 
attention has to be given to the management of the 
many services they will support. This will in¬ 
crease vastly the degree of complexity of the 
service management requirement over that for 
basic telephony services. The management sys¬ 
tems must support the management of both the 
services and the network. The multi-media 
(voice, data and video) services offered by the 
EBC may also require more sophisticated band¬ 
width and QOS management capabilities than are 
required by existing networks. 

Network management systems are required 
increasingly to support end-to-end connections, 
which may cross networks and network elements 
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owned by different organisations. In the IBCN 
case, this would be across Europe. The end-to-end 
connections will, in the future, have mobile or 
movable terminations, implying the possibility of 
handover protocols between these organisations. 

Network management systems must also sup¬ 
port an increasing number of types of user. For 
example, a telecommunications administration 
may require support for front-office staff dealing 
with customers as well as exchange or trans¬ 
mission equipment technicians and their mana¬ 
gers. In addition, the network management 
systems will be required to support users from 
other organisations, such as value-added service 
providers or business and domestic subscribers. 
The functions of the network management system 
will need to be tailored to meet these users’ re¬ 
quirements at the locations they request. Addi¬ 
tional security requirements will need to be 
addressed. 

Network management systems have to be con¬ 
structed so as to support degrees of distribution of 
processing to reflect the distribution of the users 
and the elements of the telecommunications net¬ 
work. On the other hand, the network manage¬ 
ment systems reflect a degree of centralised 
control. Non-functional requirements are also ex¬ 
tremely important in shaping the detailed physi¬ 
cal locations of processing. These include: 
performance issues, data volumes, throughput, 
and response time; cost; and security. 

These requirements are, in general, extensions 
and extrapolations of the requirements of existing 
networks, and therefore serve well to illustrate the 
trends for future telecommunications systems. 

NETWORK MANAGEMENT SYSTEM 
SPECIFICATION, ARCHITECTURES AND 
REFERENCE CONFIGURATIONS 

Responsibility for the specification of the pan- 
European TMN rests essentially with two pro¬ 
jects, although these are assisted in detail by the 
technology projects. Project NETMAN defines 
the functions and performance of the final inte¬ 
grated communications management system for 
IBCN. Project TERRACE is responsible for de¬ 
fining the evolutionary path from today’s situ¬ 
ation of islands of isolated management systems 
to the fully integrated and interconnected system 
of the future. 

Present communications management sys¬ 
tems have evolved over many years to serve the 
particular needs of their operators. The world 
standards bodies have not until recent times ad¬ 
dressed the special needs of TMN. The result has 
been that each administration has developed its 
own approach to managing its telecommunica¬ 
tions networks. This means that NETMAN has to 
take account of the output from a number of 
standardisation bodies who are addressing the 
issue from their own standpoint. Since RACE 
requires the European solution to be in accord 
with world standards, NETMAN’s task has to be 
to monitor, intercept and combine. 


The approach has been to operate on three 
broad fronts. The first is concerned with tracking 
the output of the world standardisation bodies; the 
second has been to develop methods and models 2 
to assist with representing the complexity of 
TMN functions; and finally the views of major 
players have been sought via case studies of cur¬ 
rent communications management practice. The 
ultimate aim of NETMAN is to provide a rigorous 
definition of TMN and to assist in the production 
of a functional reference model to guide the im¬ 
plementation of future TMN systems. One of the 
important models adopted by NETMAN to cap¬ 
ture its requirements is the so-called NETMAN 
cube model , which supports organisation of its 
specifications in three quasi-orthogonal axes, as 
shown in Figure 3. 



Figure 3 
NETMAN cube 
model 


The three axes of the cube are as follows: 

O The four CNA-M layers of business, service, 
network and element management. 

O Three phases of network management tasks: 
awareness creation, decision making and support, 
and decision implementation. These help to en¬ 
sure that management requirements are complete. 
® Nine functional areas which cover the full 
network life cycle: design, planning, installation, 
provisioning, maintenance, performance, se¬ 
curity, accounting, and customer query and con¬ 
trol. 

Project TERRACE will take the evolving 
functional specifications produced by NETMAN 
and develop scenarios for the introduction of 
TMN across Europe. In building on the work of 
NETMAN, these scenarios will use function allo¬ 
cation strategies which have regard for the non¬ 
functional aspects of TMN, such as size, cost, and 
any special national requirements. In addition, 
regional issues connected with the size of the 
IBCN, expected traffic flow and so on, will be 
taken into account. The output from this project 
will be a set of reference configurations 3 which 
will show how the integrated TMN is expected to 
evolve. 
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A survey 4 of the state of the art in European 
network management has been undertaken to pro¬ 
vide a current practice perspective for the work of 
the TERRACE project. 

Management of telecommunications networks 
is being automated but largely on a piecemeal 
basis. Many companies are developing proprie¬ 
tary architectures to allow such automation to be 
provided in a more systematic and integrated 
fashion by a process of evolution. In the RACE 
programme, network management architectures 
are also the subject of considerable work. Their 
definition has been undertaken by a number of 
projects but principally by project GUIDELINE 5 . 
An eclectic approach has been pursued, with the 
RACE architectures being basically augmenta¬ 
tions of architectures being developed in stand¬ 
ards organisations elsewhere. Essentially, the 
additions are to cope with particular requirements 
of IBC or the technology to be used in network 
management system development. These 
augmentations to the TMN architecture are in turn 
being submitted to the European Telecommuni¬ 
cations Standards Institute (ETSI) and CCITT for 
inclusion in new versions of the TMN standards. 

One of the key standards in the area is the 
CCITT concept of the TMN 6 . The purpose of the 
TMN as defined in CCITT M.30 is to support 
telecommunications administrations and recog¬ 
nised private operating agencies in the manage¬ 
ment of their telecommunications networks. The 
TMN can vary in size from a simple connection 
between an operations system (OS) and a single 
piece of telecommunications equipment to a sig¬ 
nificant network containing many different types 
of OS and telecommunications equipment. 

The concept is intended to be sufficiently 
general to accommodate this breadth of range. 
Clearly, the range of organisations using the TMN 
concept could be very large. None of them are 
constrained to using this approach but inter¬ 
change of management information will be much 
easier if they do. The concept of the management 
information base (MIB) in network management 
Figure 4 has ^ een widely accepted by the standards-mak- 

A possible AIP ing and similar bodies; namely, the International 

implementation Standards Organisation (ISO) in the Open Sys- 

architecture terns Interconnection (OSI) 7 , the American Na¬ 
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tional Standards Institute (ANSI) in T1M1.5 8 , the 
OSI Network Management Forum 9 and ETSI in 
NA4 10 . Information modelling concepts are also 
being considered by CCITT for inclusion in the 
TMN recommendations. The MIB is a conceptual 
repository of all the data held in the TMN about 
the network and the TMN itself. The information 
base is required to store information on network 
and system configuration, customers and ser¬ 
vices, current and historic performance and 
trouble logs, security parameters and accounting 
information. 

To date, the augmentations to the TMN stand¬ 
ards have included: 

Q Layering M.30’s OSs following CNA-M 11 to 
support element, network, service and business 
management systems. The approach allows a 
logical structuring which is natural in the context 
of multi-service networks such as the IBCN. 

0 Definition of aspects of OS internals, by intro¬ 
ducing common functions. The common func¬ 
tions are of two kinds: infrastructure functions to 
support capabilities, such as database access, user 
interfaces and communications; and user generic 
functions related to network management, such 
as configuration management, statistics and event 
management. 

© The concept of the management information 
base, a conceptual repository of all information 
required to manage the network, has been elabor¬ 
ated in the context of the M.30 models. This has 
been done by decomposing the operations system 
and by defining a specification language for the 
MIB via definition of managed objects which 
may support definition of protocol data units or 
the global conceptual schema of a distributed 
database. 

# Views of the TMN as a partially distributed 
processing system have been developed. These 
may support aspects of distribution transparency, 
for example, transparency of access, location, 
replication and possibly migration. 


TECHNOLOGY FOR NETWORK 
MANAGEMENT SYSTEMS 

The RACE TMN technology projects AIM, AD¬ 
VANCE and NEMESYS are charged with the task 
of assessing the applicability of state-of-the-art ad¬ 
vanced information processing (AIP) 12 techniques 
to various aspects of the TMN problem area. In 
doing so they identify suitable target applications 
for testing the applicability of AIP. These applica¬ 
tions are then used to form the basis for prototype 
and demonstrator systems. Full-scale applications 
are not possible in this context. These demonstra¬ 
tors and prototypes are constructed within a com¬ 
mon conceptual framework provided by the 
GUIDELINE project in the form of an implemen¬ 
tation architecture for RACE TMN. 

The projects address the applicability of AIP 
in computing platforms and infrastructure as well 
as TMN applications areas. Figure 4 gives an 
indication of the breadth of coverage. 
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Coordination of the three technology projects 
and the provision of a common interface to the 
TMN specification projects is provided by project 
GUIDELINE. This project is staffed by the prime 
contractors of the technology projects, and the 
leaders of the specification projects are associate 
members. 

Project GUIDELINE: RACE TMN 
Coordination 

The best way to describe the activities conducted 
by GUIDELINE is to give a brief account of the 
work conducted by its Technical Coordination 
Groups during the first three years of the pro¬ 
gramme: 

Advanced Information Processing (AIP) 
The aim of this coordination activity is to monitor 
the AIP research and experimentation being con¬ 
ducted in the technology projects in order to re¬ 
duce overlap of work to an appropriate minimum. 
Regular seminars are held to assist with the dis¬ 
semination of results among the TMN AIP com¬ 
munity. The AIP focus over the last period has 
included object-oriented modelling, human- 
computer interaction, advanced databases and 
distributed processing. 

A sister programme to RACE (ESPRIT) is 
conducting research into many AIP issues that are 
important to the success of RACE TMN. This 
group provides a focus for the exchange of infor¬ 
mation between the two European Community 
(EC) funded programmes. 

TMN Architecture Group This activity is 
working on an architecture 5 for use by the tech¬ 
nology projects during the RACE programme. 

Specification Assessment Group This group 
provides a focus for the assessment of the speci¬ 
fications being prepared by NETMAN from a 
technological (AIP) standpoint. 

Interface Specification Group The detailed 
specifications of the interfaces to the TMN and 
interfaces of major subsystems within the TMN 
will be prepared by this group. 

TMN Standards Group This group provides 
the TMN work area with an up-to-date account of 
the work being conducted by world stand¬ 
ardisation bodies in the TMN and related areas. 

Project AIM: AIP Applied to Maintenance 

Project AIM defines a set of maintenance recom¬ 
mendations for the IBCN. In order to provide a 
firm foundation, the project is undertaking ex¬ 
perimental studies into the application of AIP 
techniques in two problem areas: the diagnostic 
and repair functions necessary for modem digital 
telephone exchanges (GPT’s System X), and the 
diagnosis of faults on broadband networks (SEL’s 
BERKOM B-ISDN network in Berlin). 

The diagnostic technology for these two appli¬ 
cations is common and is based on second-gener¬ 
ation model-based KBS. This modern approach 


to fault diagnosis is considered to be most appro¬ 
priate to telecommunications networks since the 
KBS models can easily mimic the highly-struc¬ 
tured organisation of network elements and com- 
plete networks. The generic maintenance 
system 11 being developed by AIM arrives at diag¬ 
nostic conclusions by propagating known symp¬ 
toms (fault reports) through the model and, by 
managed searching, for example, correlates these 
symptoms with possible fault scenarios. These 
fault scenarios are further refined by comparing 
the diagnostic conclusions with a list of mean- 
time-between-failure data to identify the fault. 

Project ADVANCE: AIP Applied to 
Network and Customer Administration 
Systems 

This project is concerned with administering cus¬ 
tomer services and managing the network, in 
which IBCN offers a wide spectrum of challen¬ 
ges. 

The technology focus for ADVANCE has been 
on object-oriented modelling, distributed and 
heterogeneous databases, KBS and database in¬ 
teraction within a coherent implementation archi¬ 
tectural framework 13 . 

One such challenge of the IBCN is that of 
customer control of the network. For instance, in 
a movable (as compared to a mobile) service, the 
customer is able to connect terminal equipment 
electrically to any appropriate IBCN port irre¬ 
spective of its geographical location. When so 
connected, the customer will wish to use the 
services enjoyed at the home location. The aim is 
to conduct this service negotiation fully automat¬ 
ically from the IBCN TMN. 

Such automation raises many issues con¬ 
cerned with availability of specific services, guar¬ 
anteed performance, contracted availability and 
cross-network charging. Experimental work con¬ 
ducted by project ADVANCE has demonstrated 
that AIP techniques can help to provide such 
service level automation. 

Project NEMESYS: AIP Applied to Traffic 
Management 

Traffic management and quality of service are the 
two areas of communications management being 
addressed by project NEMESYS. In the area of 
traffic management, the task is particularly diffi¬ 
cult because no network exists which exhibits the 
characteristics expected from the IBCN. In addi¬ 
tion, managing traffic flows on large telecom¬ 
munications networks is difficult because of the 
wide range of traffic levels that can be experi¬ 
enced. 

It is likely that the IBCN will use asynchron¬ 
ous transfer mode (ATM) for bulk transport of 
data. This packet-like transmission method brings 
its own special problems concerned with source- 
rate policing. 

Project NEMESYS has approached these spe¬ 
cial problems by the development of an ATM net- 
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work simulator and by close cooperation with those 
members of the RACE community concerned with 
ATM. This has allowed the project to establish an 
experimental traffic management system which in¬ 
terworks with the ATM network simulator. Results 
to date confirm that AJP techniques offer valid 
solutions to the control of traffic flows in ATM 
networks. The technology focus for NEMESYS 
has been real-time KBS supported by object- 
oriented distributed processing platforms 14 . 

Project NEMESYS is responsible for prepar¬ 
ing detailed recommendations and specifications 
for traffic management strategies and QOS issues 
in the IBCN. 

FUTURE PLANS 

During the final two years of the RACE main 
phase, the TMN projects will be concerned with 
extending the technology investigations and con¬ 
solidating the common functional specifications 
(CFS). 

As noted earlier, project NETMAN has the 
responsibility to produce the TMN specifications, 
but the opportunity will be taken to validate these 
ideas against the AIP experimental implementa¬ 
tions being conducted by the technology projects. 
Additionally, the specifications will be subject to 
a consensus-forming activity which brings 
together the collective expertise of the RACE 
community. Aspects of the CFS will be submitted 
to ETSI for consideration in world standards 
groups. This multi-layered definition process 
should result in the first comprehensive definition 
of the complete life cycle of modem network 
management systems. This will be a major 
achievement for the RACE programme. 

In addition to supporting the CFS production, 
the technology projects will be refining their ex¬ 
perimental implementations to support two main 
phases. 

The first will be to gain a deep understanding 
of how AIP technology can be utilised to enable 
the cost-effective realisation of pan-European 
TMN systems. These investigations will look at 
both the special techniques required (KBS, dis¬ 
tributed databases, and so on) and the important 
issue of scaling the technology to the large system 
that will be required. 

The second main phase will address the area 
of integration. During the first three years, the 
technology projects shared the results at a techno¬ 
logical level: the integration of their experimental 
system to produce an embryo TMN was not at¬ 
tempted. A cross-project task has now been estab¬ 
lished to realise the goal. The investigations will 
assist the validation of the technical architecture 
for the TMN, which has been one of the signifi¬ 
cant results of the research. 

Work is now beginning on the planning of the 
RACE II programme. This will build on the re¬ 
sults obtained to date and focus the technology 
onto specific network management applications. 

In parallel with discharging its obligations to 
RACE, the BT team members have been seeking 


actively opportunities for the use of the technol¬ 
ogy in BT’s product lines. The network diagnosis 
technology (project AIM) is now being used in 
the Concert™ programme and the service man¬ 
agement ideas developed in project ADVANCE 
will have an impact on future intelligent network 
offerings for BT. The TMN architectural studies 
being conducted by GUIDELINE are having an 
influence on the company-wide CNA-M acti¬ 
vities. 

CONCLUSIONS 

This article has introduced the work being con¬ 
ducted by the six projects charged with develo¬ 
ping definitions and technology to support the 
introduction of a comprehensive system to man¬ 
age modern telecommunications across Europe. 
During the first three years, excellent results have 
been obtained and these are having an influence 
on both company thinking and emerging product 
lines. 

To a large extent, these results have validated 
the collaborative approach to such extensive pro¬ 
jects. Multi-company, multi-national projects are 
not without special problems concerned with dif¬ 
ferent goals, separate cultures and not least lan¬ 
guage and distance issues. But given a 
well-defined goal in a pre-competitive and pre- 
normative sphere, excellent results can be 
achieved. The benefits include lower risk, shared 
costs, new approaches and the potential of achiev¬ 
ing effective standardisation. 
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Future Challenges for Network Management 

T. A. FITCHETT, and M. H. REEVEt 


New network technologies will be introduced over the coming decades to offer new services and to enable 
operating cost reductions. These will produce significant challenges for network and service management 
systems. This article considers these changes and their impact on network management systems. 


INTRODUCTION 

Over the next decade, telecommunications custo¬ 
mers will require an increasing range of new 
services, packaged in various ways, available glo¬ 
bally and able to interwork across networks pro¬ 
vided by more than one telecommunications 
operator. In addition, customers will need to be 
able to control key aspects of their service (in¬ 
cluding turning it on and off) themselves. 

These new services will require a range of new 
technologies and systems to be present in the net¬ 
work (for example, broadband systems for inter¬ 
connecting local area networks (LANs)). In 
addition, BT and other network operators will be 
introducing new technologies purely to reduce 
operating costs. Examples here might be pair-gain 
systems in the copper local loop and managed 
transmission networks based on the synchronous 
digital hierarchy (SDH) in the core network. 

Each of the statements just made about the way 
customers will use services, new services them¬ 
selves and the new technologies to support them 
will each provide significant new challenges for 
network and service management systems. 

On top of a continuing drive to integrate and 
automate management systems and to provide 
them on an end-to-end basis, these changes 
promise an exciting decade for management sys¬ 
tem development as BT pursues its aim to become 
the top global telecommunications operator. 

This article considers some of the above dri¬ 
vers and changes, assesses their impact on net¬ 
work management systems and describes some of 
the ways that technology can be harnessed to meet 
the challenge. 

DRIVERS FOR CHANGE 
New Services 

New services provided on the network will typi¬ 
cally involve new network elements, connected 
in new topologies and requiring new or enhanced 
descriptions of the items to be managed. This 
alone will provide a challenge to the network 
management systems. However, it is perhaps 
more fundamental that these new services tend to 
break the easy one-to-one relationship between 
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the physical element and the service seen in the 
present telephony network. 

Consideration of two broad classes of new 
service will serve to illustrate this. 

First, new services requiring some aspect of 
network intelligence can be considered. The de¬ 
livery of diverse telephony-based services in a 
flexible way by separating switching and call 
processing is termed an intelligent network 1 . With 
such intelligence in the network, the almost static 
relationship between the physical network and 
the network service is removed. The service logic 
embedded in attached processors can alter the 
operation of the basic telephone call to provide an 
enhanced ‘service’. 

For example, in the case of an intelligent net¬ 
work providing a network-based call distribution 
feature routing calls to a number of sites based on 
time of day and call load, how does the network 
provider test the service in the event of reported 
faults? Is the base network at fault (logically or 
physically), the service logic routing the calls or 
the network database? Indeed, a knowledge of 
previous call load is necessary to determine the 
correct routing of any particular call. The points 
of failure are no longer fixed nor are they easy to 
test in the operational network. 

This simple example serves to show that such 
services will not only require management of new 
physical network elements (the attached proces¬ 
sors) but will also require that service logic and 
databases are considered within the ‘network’ to 
be managed. 

Such network intelligence typically uses the 
CCITT No. 7 (C7) signalling system for control 
information. Such non-circuit-related signalling 
will place an increased load and emphasis on the 
C7 network. Hitherto it has not been necessary to 
manage this network; reliance has been placed on 
switch management to cope. It is inevitable that 
the emerging intelligent services will require that 
this network is also managed. 

The second broad class of new service that 
might be considered is that requiring some broad¬ 
band or multi-service aspect. Such networks 
might use frame relaying 2 or asynchronous trans¬ 
fer mode 3 (ATM) techniques to interconnect 
LANs, provide mainframe computer interconnect 
or to provide mixed voice, video and data services 
over the same network. 
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Here again there are new network elements, in 
this case frame relay or ATM switches and multi¬ 
plexers. However, the additional challenge comes 
from the need and ability to ‘nest’ services and/or 
to combine services down a single transmission 
pipe. As an example, a customer’s Ethernet LAN 
might be connected to a BT-provided frame relay 
service, combined with video and computer inter¬ 
connect data to run over an ATM service, and the 
ATM cells carried over an SDH transmission 
link 4 . The frame relay service must be managed 
end-to-end while actually nested within the ATM 
service, which has also to be managed end to end. 
Since each is carried over the same fixed through¬ 
put transmission link, sudden demands from the 
computer interconnect might adversely affect the 
frame relay or video service, resulting in a need 
for the network management system to include 
priority or policing schemes. 

Packaging of Services 

New services will not only be provided individ¬ 
ually; it is likely that services will increasingly be 
combined in ‘packages’. Charge card access to a 
corporate virtual private network might be an 
example. This will present a new challenge to the 
management systems, which will need the flexi¬ 
bility to manage services in a number of combi¬ 
nations and still provide compatible operations 
such as fault reporting and correlation. 

Customer Control 

Within the constraints of security and network 
integrity, visibility and control of the network will 
be demanded by many larger business customers. 
BT will deliver this type of capability to custo¬ 
mers under the Concert™ programme, and com¬ 
patibility with the Concert™ programme is a 
requirement for all customer-facing systems. The 
major customer service systems, used by network 
operators, such as BT’s Customer Service System 
(CSS), will need enhancement to operate with this 
type of customer control. 

Customers will demand management informa¬ 
tion to improve their decision-making processes 
for their communications service. They will also 
expect the ability to control their service usage as 
their business needs dictate. As an example, the 
installed network for such customers must be able 
to support the move of bandwidth from video 
conferencing to incoming 0800 lines to outgoing 
public switched telephone network (PSTN) lines. 
Besides such basic networking ability, the net¬ 
work administration systems must be able to track 
and control such changes. 

Cost Reduction and Quality 
Improvement 

Two of the major costs for a telecommunications 
company are capital depreciation and the cost of 
administering the network. Network administra¬ 
tion has a significant labour cost and as such is a 
target for cost reduction. There will be limits to how 


much administration systems alone can improve 
the efficiency of existing operations. Combining 
new network technologies with advanced adminis¬ 
tration will provide the best route to continual cost 
reduction. To maintain and improve the level of 
service quality while reducing costs will require 
increased levels of automation throughout the net¬ 
work administration functions. The introduction of 
managed transmission networks based on SDH 
equipment into the core network is an example of 
new technology enabling cost reduction and im¬ 
proved network administration. 

These new networking technologies will chal¬ 
lenge the current view of a network element. For 
example, in the transmission realm, the element 
is an individual multiplexer or line system. Its 
position within the network hierarchy and impact 
upon the rest of the network is a network control 
level function. As multiplexers become more in¬ 
telligent and understand their interconnections, 
there will be a blurring of these management 
levels. The elements that the network control 
level manages may become sub-networks of 
multiplexers which provide paths that are built 
together into end-to-end networks. 

The new network technology will increasingly 
enable the construction of networks that do not 
affect service when they break. For example, if a 
PSTN exchange detects a link failure on one of its 
ports, it will route all new calls over an alternative 
route. The only customers to experience failure 
would be those engaged on a call over the link when 
it failed, who have to clear down and dial again; 
most customers would see no failure in the net¬ 
work. Resilient transport networks that can heal 
themselves in service protection times, and switch¬ 
ing technologies that route individual frames, can 
deliver a network service where the customer does 
not normally see any individual failures. 

New network technologies will bring their 
own opportunities for new operational practices. 
If the network technology provides for remote 
configuration, then the provisioning process can 
be automated—all the way to the customer’s 
desk, under the customer’s control if appropriate. 

Each new network technology will challenge 
some of the ways existing administration acti¬ 
vities are performed. Planning, data building, per¬ 
formance measurement and analysis are 
examples of activities that will change as new 
technologies are deployed in the network. 

User Organisation 

Since privatisation, BT has undergone several 
organisational changes. To continue to meet the 
demands that customers will place on a modern 
communications service, BT will aim to improve 
continually the way business processes are car¬ 
ried out. The total quality management (TQM) 
philosophy of continual improvement will be a 
constant force for change over the next decade. 
These changes to the organisation and to the skills 
and responsibilities of the network management 
systems users will require the network manage- 
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ment systems to be flexible in order not to present 
barriers to the change. 

Competitive Environment and 
Globalisation 

The telecommunications environment in the UK 
has moved from a monopoly to one of regulated 
competition, a change now being followed in 
some other parts of the globe. Customers will use 
multiple network operators for their communica¬ 
tions needs, as they already do in the USA, and 
the international call model , whereby BT is only 
responsible for half of the call, will become more 
common within the UK. Interworking and colla¬ 
boration with other network operators will have 
to be established. For example, the traffic man¬ 
agement problems from focused overloads, such 
as telethons, will not be completely under BT’s 
control. 

The challenges this brings will be similar to 
those posed by the move to personal mobility ser¬ 
vices. The ability of a customer to move between 
the fixed, cellular and GSM (groupe speciale 
mobile) networks as true personal mobility 
becomes a reality will mean that the operational 
issues of such networking must be addressed. Not 
only must the networks physically interwork, the 
operational support systems of such networks must 
be able to interwork seamlessly, so that service 
provision, maintenance and billing appear unified 
for the customer, even though the networks them¬ 
selves may be owned by different operators. 

As an example in fault reporting, will it be 
acceptable for a BT customer to telephone BT and 
complain that he/she cannot get through to a 
client, whose service is provided by Mercury, and 
for BT to answer ‘our network is OK, you need 
to complain to Mercury’? End-to-end network 
management across multiple networks will be 
required, meaning that operational support issues 
such as testing standards will need agreement 
between operators, and ultimately some ‘view’ or 
electronic interface between different operators’ 
support systems will be established. 

Besides the collaboration with competitors 
that liberalisation brings, there will also be the 
need to be as aggressive as regulation allows in 
the development and deployment of new services. 
Volume-related call pricing, charge cards and 
other such services all require changes to the 
network administration systems. 

Many of these issues are seen in the move from 
a national service provider to a truly global oper¬ 
ation, where networks from several operators may 
be involved in providing the end-to-end service. 

CURRENT OPERATIONAL 
ENVIRONMENT 

In considering how to respond to the drivers for 
change, it must be recognised that network oper¬ 
ators are building on a current situation that is still 
evolving and that has a number of known defi¬ 
ciencies. Some of these are as follows: 


Service-Dependent Systems 

The present services offered to customers are not 
all delivered from a uniform network platform. 
Services such as private circuits use a separate 
switching network to that of the PSTN (even 
though they share common core transmission fa¬ 
cilities). These separate networks often have their 
own specific support systems and organisations. 
The replication that this can entail can make the 
deployment of new services costly and ineffi¬ 
cient. 

Quality-of-Service Measurement 

The performance of the service delivered to 
customers is measured in a fragmented way. The 
networks and support systems currently in use 
were not designed with the ability to measure in 
detail an individual customer’s quality of ser¬ 
vice. Information is predominantly available on 
the network and its elements, not on the total 
service or the service provided to individual 
customers. 

Network Elements 

The intelligence in the equipment currently de¬ 
ployed within the network concentrates primarily 
on its basic function of processing calls or simple 
point-to-point transmission. The present plesio- 
chronous digital hierarchy offers little in the way 
of management facilities for the network oper¬ 
ator. With no internationally agreed management 
capability, each manufacturer offers its own; this 
makes it impossible for equipment to be mixed at 
will. 

In the local access network, copper is the pre¬ 
dominant, labour intensive, means of delivery for 
voice services, with specialised services using 
their own separate access networks. Unified ac¬ 
cess methods are still in the early stages of de¬ 
ployment (see the special issue of the Journal on 
local access (April 1991)). 

Islands of Automation 

Current network support systems have compen¬ 
sated for the lack of management functions within 
the network elements and have focused on spe¬ 
cific operational functions. These systems have 
mechanised network operations in a fragmented 
way. This approach has led to the current systems. 
The challenge of the immediate future is to enable 
these to interwork to produce an integrated, auto¬ 
matic approach. 

Labour Intensive 

If network operators continue to use a multitude 
of diverse support systems and network elements, 
a great variety of operational units and control 
centres will be required, and the lack of integra¬ 
tion and consistency in these systems demands 
the use of considerable effort, representing one of 
the major costs of network operations. 
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NEXT-GENERATION SYSTEMS 

A number of drivers can be identified that will 
impact on the next generation of systems. In 
general, technology trends will provide enablers 
to improved management systems, particularly 
when combined with improved administrative 
methods. 

Technology Trends 

Generic Systems 

The next generation of administration systems 
will be developed within an architectural frame¬ 
work (CNA-M) which provides the basis for in¬ 
terworking. A small number (40) of key systems 
will be used and this will reduce the development 
and running costs of the systems themselves. 
Each system will undertake the tasks for a func¬ 
tional area and be linked to associated systems, 
for sharing data and for passing work as it flows 
through the systems. 

New software technologies, such as automated 
software production and significant reuse of 
major components, will be used in these systems 
to ensure that their development costs are con¬ 
strained and that they are able to adapt to the types 
of changes identified earlier. 

Computing Technology 

The same technological advances that enable 
the new network technologies are continuing 
rapidly to improve the computer world. The 
computing power that once cost millions of 
pounds is now available for thousands (the IBM 
PC was not available 10 years ago). The real cost 
of computing power is falling in the order of 
25% per year. 

As well as this rapid price reduction, the com¬ 
puting industry is moving from proprietary archi¬ 
tectures to systems based on ‘open’ interfaces. No 
one vendor ever provided all the computing needs 
of a telephone company, and problems are en¬ 
countered when proprietary systems have to be 
integrated together. The availability of open sys¬ 
tems across a range of computing platforms 
makes the development of integrated support sys¬ 
tems a simpler task. 

Savings are also being made in the operational 
costs of computing systems. Increasing computer 
power and advanced computer systems manage¬ 
ment tools enable the consolidation of computer 
centres, fewer software licences and other oper¬ 
ational savings to be made. 

Advanced Information Processing 

Progress is also being made in advanced infor¬ 
mation processing (AIP) 5 to make software sys¬ 
tems that are more adaptable and intelligent. The 
problems posed by the real-time nature of net¬ 
work operations are not trivial, but the progress 
to date is such that technology can be expected 
to improve the type of software used in most 


operational support systems over the next five 
years. 

Network Administration 

The successful development of network adminis¬ 
tration is crucial to the future of network operators 
such as BT. It will enable cost reduction, improve¬ 
ment in quality, and faster and more flexible 
response to customer demands. Failure to meet 
the challenge will result in higher costs and slow 
response. It must be recognised that the function¬ 
ality of the next generation of network manage¬ 
ment systems will be governed by the type of 
network being operated and the way the company 
wants to operate it. Certain major features will be 
evident: 

Flow-Through 

The consolidation of network administration into 
centralised operational units still requires exten¬ 
sive manual effort using systems that are not 
integrated. Future systems will be characterised 
by automatic flow-through whereby an event, be 
it a customer order or fault in the network, triggers 
off a set of actions in an integrated set of computer 
systems. These then automatically perform the 
relevant workstring to respond to that event. The 
processing of the workstring is such that the re¬ 
sponse has the minimal amount of human inter¬ 
vention necessary. 

Figure 1 illustrates the flow-through between 
systems for the example of automated traffic 
management. A further example, covering provi¬ 
sion of service, is given in Reference 7. 

Rapid Deployment 


Figure 1—Example 
of flow-through for 
capacity 
management 


Fast feature introduction will be demanded by the 
product managers of network services. Waiting 
years for a switch software release or change to 
an operational system will not be acceptable. 
Future operational support systems will be more 
flexible and be able to accept new functions in 
relatively short time-scales. 
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Customer Control 

Direct customer control of the network, either as 
individual services or combined as a whole in a 
virtual private network service, can reduce BT 
manpower. The means of control will vary from 
simple MF4 tones and voice response, up to a 
Concert™ workstation in the customer’s 
premises. The means of delivery of customer 
control will vary depending upon the customer 
and the service being controlled. 

Improved Customer Service 

Quality of service to customers will be improved 
by future generations of network administration 
systems in two major ways: 

# Support of Self-Healing Networks New net¬ 
working technology can operate as semi-autono¬ 
mous units. The need for all of the network 
management and support functions to reside in 
systems external to the network elements will be 
reduced as the network elements gain substantial 
intelligence. The ability of the network elements 
to adapt to changes without human intervention 
will improve the level of service. The new net¬ 
work elements, while adapting to changes, will 
also report the causes, so that longer-term correc¬ 
tive action can be taken. 


# Proactive Maintenance Continuous surveill¬ 
ance of the network coupled with automatic test¬ 
ing directed by an expert system will become the 
norm ensuring that service-affecting faults are 
minimised. 


FUTURE MANAGEMENT EXAMPLE 

To show how some of these forces will drive 
network management in the future, consider the 
following hypothetical example (Figure 2): 

The seiyice is an international virtual private 
network service supplying the total network 
needs of multinational companies from basic 
voice services to 0800 services and data services. 

The network is made up of a core transmission 
network onto which switching nodes have been 
added. The inter-node links and customer-node 
links are either owned by the operator or leased 
from other operators. In country A, no links are 
owned, in country B some are owned and some 
are provided by alternative operators. 

The scenario : The customer’s network man¬ 
ager (located at site 4) needs to change the auto¬ 
matic call distribution function. A marketing 
campaign in country B is so successful that there 
are not enough operator positions at site 2 to meet 


Figure 2 
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the need, the overflow is to be directed to the 
evening shift at site 4 in country A. 

The management (Figure 3): 

(A) Via a management terminal, the customer 
alters ‘his’ network’s automatic call distribution 
service. 

(B) The service management system vali¬ 
dates and records the change, updates the billing 
system (calls that were once purely handled in¬ 
country may now be going to country A), and 
updates the service records used by customer-fac¬ 
ing staff. 

(C) The service management system requests 
network change from the network control sys¬ 
tems. 

(D) The network control system ‘evaluates’ 
the change, works out any new network assign¬ 
ments, and updates, among others, planning sys¬ 
tems, network records, and traffic management. 

(E) The network control system instructs the 
network element’s management systems to rec¬ 
onfigure the network (in this case an intelligent 
network service control point). 

The whole sequence demonstrates the flow¬ 
through required to operate the service efficiently. 
Only the minimal amount of intervention is re¬ 
quired by the network operator between the cus¬ 
tomer and the customer’s network service. 

We can consider this network example from 
other viewpoints. How can the response to cus¬ 
tomer requests be automated? It could be the 
testing of the private circuit between site 5 and 
site 4, which runs over links not owned by the 
network operator (multiple network testing). 

Or it could be a request for the doubling of the 
capacity at site 1 for the video conferencing service 
for a month while a special conference is being held 
(local access network capacity assignment). 

From the highest level of the international 
virtual private service customer support system to 
the local access capacity assignment system, the 
network administration systems must be inter¬ 
linked with the right functionality to ensure that 
the service offered is truly world class. 

GETTING THERE 

Earlier articles have explained how the key sys¬ 
tems for future operations have been identified 7 
and how the requirements of strategic systems 
areas have been analysed and the future architec¬ 
ture defined 8 . 

Achieving this future vision will be by a com¬ 
bination of evolution of current systems and the 
creation of new systems. 

In some areas of operation, accelerated net¬ 
work modernisation will deploy new network 
elements at such a rate that the best option will be 
to deploy new operational support systems based 
on the target architecture, and remove the existing 
systems along with the old network elements. 
Such aggressive modernisation should produce a 
significant uplift in capabilities and bring major 
operational benefits. 



Figure 3 

Management 

operations 


In other operational areas, existing systems 
will be enhanced, adapted to meet the target archi¬ 
tecture and interlinked with other systems. The 
benefit this brings will be one of continual im¬ 
provement rather than drastic and expensive 
change. 

The approach adopted will depend upon the 
existing investment in the network and support 
systems and how well they meet the operational 
needs of BT over the next decade. 

CONCLUSION 

The next decade will see continuing demands on 
network administration systems to help BT meet 
its customers’ needs by reducing operating costs, 
achieving quality objectives and enabling custo¬ 
mers to view their facilities and services. 

Coupled with the modernisation of the network 
elements themselves, network management will be 
crucial to the success of the company. By building 
on the successes to date, and the wholehearted 
adoption of new technologies within a consistent 
architectural framework, BT can be confident of 
having the systems it needs in the final decade of 
the 20th century and into the 21st century. 
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30th European Telecommunications Congress 

M. SAUNDERSt, and K. MORGAN* * 


INTRODUCTION 

The 1991 annual congress of the Federation of the 
Telecommunications Engineers of the European 
Community (FITCE) was hosted by the French 
Association des Ingenieurs des Telecommunica¬ 
tions (AIT) in Strasbourg in September 1991. 
With the theme for this year’s congress as ‘Pan- 
European Networks and Services’, Strasbourg, 
which is the home of the European Parliament, 
was aptly chosen for its cultural and innovative 
history in communications. It was here that 
Gutenberg printed the first book, which was the 
Holy Bible, and where the French national an¬ 
them, Les Marseillaise, was first performed for 
the public. 

The location of the 30th FITCE congress was 
the Palais des Congres et de la Musique, situated 
on the outskirts of the city and provided a modem, 
spacious, well equipped venue, which catered 
well for the technical seminars and a number of 
social functions held during the week. 

OPENING CEREMONY 

The congress was opened on the morning of 
2 September and attracted a number of distin¬ 
guished speakers. M. Irlinger, Director of France 
Telecom for the Alsace Region, welcomed every¬ 
one and commented on the pertinence of the 
conference theme in establishing the types of 
networks that customers wanted. Colin Shurrock 
of BT, President of FITCE, spoke of the rapid 
developments in both the commercial and tech¬ 
nological aspects of telecommunications and 
talked of the twin concepts of competition and 
cooperation. He emphasised the role of FITCE in 
promoting understanding and the exchange of 
ideas. 

M. Roulet, President of France Telecom, pur¬ 
sued a similar line of thought and spoke of the 
roles of the various different players in the tele¬ 
communications arenas. M. Rohmer, repre¬ 
senting the Mayor of Strasbourg, commented on 
the appropriateness of Strasbourg as the con¬ 
ference venue on this occasion. 

The presence of Herr Gorts, the German State 
Secretary of the Ministry for PTT, gave an addi¬ 
tional international dimension to the opening 
ceremony. He outlined the significance of the 
unfolding developments in communications 
throughout Europe. M. Rausch, the French Min¬ 
ister of Telecommunications, reflected on the ef- 
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feet of new telecommunications services on the 
way companies conduct business in Europe, and 
of the importance of the communications infra¬ 
structure on their ability to compete effectively on 
the world scene. An interesting highlight of the 
opening ceremony was the first public perfor¬ 
mance by a string quartet of an overture entitled 
‘An Invitation to European Dialogues’, which 
was composed specially for FITCE by a young 
composer, Stuart Thompson, a student at the 
Royal Academy of Music in London. 

TECHNICAL PAPERS 

The Pan-European Networks and Services theme 
of the congress provided a good range of technical 
papers covering topics such as new services, 
mobile communications systems, European 
standardisation, integrated broadband communi¬ 
cations networks, private networks and European 
cooperation. 

The standard of presentations was generally 
good although occasional failures in the conti¬ 
nuity of the visual projections and translations 
detracted from what were otherwise very compe¬ 
tent performances. 

A brief summary of the papers from BT auth¬ 
ors is given below: 

‘Specification of Network Performance: Role 
of Customers Requirements on National and Pan- 
European Services’ by A. P. Oodan. 

The paper described the methodology used for 
specifying end-to-end performance specifica¬ 
tions using functional models of the network, 
methods of obtaining customers’ requirements 
and gap analysis techniques. 

‘Today’s ISDN, an Overview for Potential 
Users of ISDN CPE’ by R. Haslam. 

The paper examined the current situation and 
future scenarios for ISDN customer premise equip¬ 
ment (CPE) with particular focus upon ISDN 
implementation problems and the emerging 
standards as a solution to users needs. 

‘Supporting the Customer Interface’ by A. 
Houghton, D. Pollard, and N. Millard. 

The paper described the work being carried out 
to develop expert systems as a means of improv¬ 
ing customer service through interactive dialogue 
between customer-facing staff and their computer 
support systems. 

‘A Strategy for Providing an On Demand Ser¬ 
vice in a Copper Environment and Considering 
Future Technologies’ by A. Hill, and R. Wardle- 
worth. 
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Left to right: R. Trieflinger (Germany), J. de Moitie (Belgium), H. Witberg (Netherlands), 
Andy Valdar (UK), and Miet Loix (Belgium) 


Andy Valdar, BT, 
(second from right) 
chairing the 
Pan-European 
Radiocommunications 
Using Mobile Radio 
Session 


The paper described work carried out in East 
Anglia to ensure that the correct copper capacity 
is planned and provided in the right place, at the 
right time, ensuring customer provision needs are 
met whilst maximising the return on investment 
in line plant. 


‘Guidance in the Development of Integrated 
Multimedia Telecommunications Services’ by N. 
Watkinson and K. Dickerson. 

The paper described work carried out under 
the RACE programme to provide designers with 
tools enabling them to develop usable integrated 
multi-media telecommunications services. 


‘A New Approach to Network Structure using 
SDH’ by C. Smith. 

The paper described the development of the 
synchronous digital hierarchy (SDH) network by 
BT and the programme of phased implementation 
in the UK, focusing initially on the private circuit 
sector, but evolving to eventually replace the 
existing plesiochronous systems. 


Ron Haslam, BT— 
Award for Best 
Presentation Material 



CONGRESS AWARDS 

Three awards were presented at this year’s FITCE 
congress. The Paper Selection Committee, 
chaired by Gilbert Ferrieu and including Andy 
Valdar of the UK, awarded the Best Technical 
Paper Award to Madame Martine LaPierre (Alca¬ 
tel France) for her paper ‘Introduction of Broad¬ 
band Services’. 

The congress gave awards for Best Presenta¬ 
tion Material to Ron Haslam (BT), and for Best 
Young Engineer of the congress to Jan Vande- 
drinck (RTT Belgium) for his ‘Bound for a Pan- 
European Network’ presentation. 

STUDY COMMISSIONS REPORT BACK 

A key area of interest during this congress was the 
report back from the two FITCE study commis¬ 
sions currently investigating the local loop and 
telecommunications engineering training. The 
commissions were set up to study specific prob¬ 
lem areas in these fields and comprised a small 
team of FITCE members from different European 
countries. The objective of these commissions 
was to examine the problem areas from different 
viewpoints, to investigate new ideas brought 
about by shared research and to communicate 
developments and findings to the members of 
FITCE. They provide an active component in the 
work of FITCE by encouraging members of dif¬ 
ferent nationalities to participate in raising infor¬ 
mation standards among the membership. 

The Local Loop Commission, whose member¬ 
ship included Mike Parry and Peter Smith of BT, 
focused on quality-of-service improvements and 
cost reduction in local network operations. The 
commission was established to study the local 
network infrastructures in the member countries 
and to develop a series of common performance 
metrics that would enable cross-comparison of 
quality of service between European states. The 
conclusions of the study group recognised that, 
while other elements of the network infrastruc¬ 
ture appeared to be well defined—for example, 
switch, transmission etc—strategies for the local 
loop were patchy and unclear in most countries, 
resulting in high costs and quality-of-service 
problems. It was obvious that more work needed 
to be carried out in this area but the findings of 
the commission would provide a good starting 
point for further research. 

The work of the Training Commission focused 
on the training needs of telecommunications en¬ 
gineers from 1992 onwards, and the UK played a 
prominent role through the efforts of Dave Corrie 
from the BT Management College. Their research 
had found that changes in the markets through 
liberalisation and technological developments 
had resulted in organisations becoming more ‘or¬ 
ganic’ and required engineers and engineering 
managers to have a broader range of skills than 
had been necessary in the past. For example, 
engineering managers of the future would require 
knowledge of finance, marketing, products and 
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services, competition and regulation, and be com¬ 
puter literate as well as having a formal engineer¬ 
ing education. The commission concluded that 
there were a number of options available to de¬ 
liver such training, but the problem was the 
choice of the most suitable training solution from 
the mass of material currently on offer. Several 
recommendations were proposed, the key ones 
being the involvement of all FITCE member 
countries in the study group work and estab¬ 
lishing contact with a European organisation for 
the development of a standard for telecommuni¬ 
cations engineering training and development. 

The work of both commissions was well re¬ 
ceived by the congress and prompted a request 
from the FITCE President for proposals of other 
possible problem areas that would warrant future 
study group activity. 

TECHNICAL VISITS 

An important part of the congress has become the 
technical visits, where delegates have the oppor¬ 
tunity to see telecommunications examples in the 
host country through visits to sponsoring organi¬ 
sations. This year, visits were to Clemmesy (elec¬ 
tronics), Telmat (software), Alcatel (PABX and 
videotext), Bosch ANT (microwave and fibre op¬ 
tics) and France Telecom (operations manage¬ 
ment). 

ROUND-TABLE DISCUSSION 

The final technical session of the congress was 
concluded by a round-table discussion on pan- 
European telecommunications and its importance 
to a united Europe. The discussion group con¬ 
sisted of M. Garric (European Commission (EC), 
Brussels), Bruno Lasserre (French Ministry of 
PTT), Yves Gouiffes (France Telecom), Ruth Cox 
(PTT-Telecom, Netherlands), Michel Huet 
(Cogecom), Michel Lucus (Bank Credit Mutuel 
Alsace) and Philippe Bette, a journalist. The dis¬ 
cussion centred on the efforts of the EC to pro¬ 
mote competition through liberalisation, the 
encouragement of technical harmonisation by the 
development of technical standards and the bene¬ 
fits that would be accrued to the customer from a 
pan-European perspective. 

The discussion concluded that, although tele¬ 
communications would be fundamental to the 
success of a free European market, currently not 
enough concern was being shown by the EC 
politicians to ensure that a controlled pan-Euro¬ 
pean approach is established. Rather, it is being 
left to national bodies to pursue a degree of tech¬ 
nical standardisation while operating within a 
loose EC regulatory framework. 

SOCIAL AND CULTURAL EVENTS 

The FITCE congress gives the opportunity for 
delegates to meet in more informal surroundings 


and sample the cultural delights of the host 
country. A number of events were laid on by the 
sponsoring organisations with the highlights 
being the ‘Sons et Lumieres’, a light and music 
performance in the 14th century cathedral of 
Strasbourg, and a visit to the Postal Museum at 
the smal 1 town of Riquewihr situated in the Alsace 
region of France. 

FITCE GENERAL ASSEMBLY 

The congress was rounded off with the FITCE 
annual general meeting on the morning of 7 Sep¬ 
tember. Two key proposals were passed by the 
meeting warranting further research and action. 

The ‘opening up’ of Eastern Europe to the 
West has implications for a wider European Com¬ 
munity membership. A proposal to re-draft 
FITCE membership to include these geographic 
regions was agreed. 

A proposal to set up another study commission 
was also agreed by the congress. The study com¬ 
mission, proposed by the UK and chaired by Tony 
Mullee, BT Worldwide Networks, was to carry 
out research on the specification of network per¬ 
formance, focusing specifically on customers’ re¬ 
quirements. A decision was also made to extend 
the study commission on the local loop. 

1992 CONGRESS VENUE AND THEME 

The 31st FITCE congress will be hosted by Aso- 
ciacion Espanola de Ingenieros de Telecomunica- 
cion, the Spanish national association of 
telecommunication engineers, and will take place 
in Granada and Seville from 27 September-2 
October 1992. The theme for the congress will be 
‘Telecommunications and the Single European 
Market’, concentrating on the impact of telecom¬ 
munications in European economic development 
and the need for strengthening telecommunica¬ 
tions in the pan-European industrial and service 
sectors. 

CONCLUSIONS 

The 31th FITCE congress was an educating and 
enjoyable event, with a good mixture of technical 
and social events set in a culturally stimulating 
location. The technical papers were well received 
and the feedback from the study commissions 
brought an enthusiastic response from delegates. 
There is always a danger that congress holders 
may try to outdo efforts of previous years, but the 
French Association des Ingenieurs de Telecom¬ 
munications must be congratulated on organising 
a very stimulating and entertaining event. 

Thanks must also go to France Telecom and 
the many sponsoring organisations that made the 
congress a success, the Comitte de Direction and 
last but not least Tapash Ray, the Assistant Secre¬ 
tary of the UK FITCE Group, for his many efforts 
on behalf of the UK delegates. 
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THE INSTITUTION OF 
BRITISH TELECOMMUNICATIONS 

ENGINEERS 

(Founded as the Institution of Post Office Electrical Engineers in 1906) 


General Secretary: Jon Inchley, Post Point 102, 203 High Holbora, London WC1V 7BU; Telephone: 071-728 9798. Membership and 
other queries should be addressed to the appropriate Local-Centre contact point as listed on p. 284 of this issue of the Journal. 


Aberdeen Centre 

All meetings unless otherwise stated will be held in Lecture 
Theatre No. 1, City Communications Centre, 9 Bridge Street, 
Aberdeen, commencing at 14.00 hours. 

5 December 1991: Operation Sovereign One Year On by Paul 
Duffin, General Manager Customer Services, Scotland. 

14 January 1992: Satellite Communications—A Personal Vision 
of the Future by Martin Bath, VSAT Project Implementation 
Manager. 

4 February 1992: Communications in Chaos by Dr. David Lea¬ 
key, Group Technical Advisor. 

12 March 1992: BT—European Leaders by Mike Bett, Vice- 
Chairman, BT. To be held in the Concert Hall, Strathclyde Suite, 
Glasgow, commencing at 15.00 hours. 

East Anglia Centre 

15 January 1992: Major Customers*Needs: A Customers* View¬ 
point by P. Smith, Manager Communications Services, Sun 
Alliance Insurance Company. To be held at 3rd Floor Conference 
Room, St. Peter’s House, Colchester, from 14.00-16.00 hours. 

12 February 1992: BT Marine by R. Struzyna, General Manager 
Technology, BT Marine. To be held at the Pierce Room, Assem¬ 
bly House, Theatre Street, Norwich. 

February/March 1992: Visit to BT Marine at Western Docks, 
Southampton. Members will be notified of details nearer the 
time. 

18 March 1992: Telecommunications in Chaos? by Dr. David 
Leakey, Group Technical Advisor, BT. To be held at the 3rd Floor 
Conference Room, St. Peter’s House, Colchester, from 14.00- 
16.00 hours. 

East Midlands Centre 

All meetings will commence at 14.00 hours except where stated 
otherwise. 

20 November 1991: Network Management in the 1990s by Steve 
Heap, Manager, Network Management Control Centre. To be 
held at Leicester University, commencing at 17.00 hours. 

22 January 1992: Local Access Network Forum. Local presenta¬ 
tions and discussion. Midlands Personal Communications and 
Worldwide Networks. To be held at the Ex-Servicemen’s Club, 
Peterborough. 

19 February 1992: Understanding BT Finance by Tom Leitch, 
Financial Analysis Manager, PC Midlands. To be held at Nottin¬ 
gham University. 


18 March 1992: Telecommunications—A Worldwide Oppor¬ 
tunity by Bruce Bond, Director, BT Products and Services. To be 
held at Leicester University. 

15 April 1992: Sovereign Plus One. Joint presentation by Mid¬ 
lands senior managers from Personal Communications, Business 
Communications and Worldwide Networks. To be held at Lei¬ 
cester University. 

East of Scotland Centre 

All meetings are from 12.00-14.00 hours unless otherwise 
stated. 

20 November 1991: Networks—Its A Gas! by Ian Harkness, 
British Gas. To be held in the Conference Rooms, Telephone 
House, Ward Street, Dundee. 

11 December 1991: A Customer*s View ofBT by Douglas Man- 
son, Information Systems Operations Manager, Standard Life. 
To be held in Room E2/3, Caledonian House, Canning Street, 
Edinburgh. 

22 January 1992: At Your Service by Sandy Laing, Operator 
Services Manager. To be held in Room 340, Telephone House, 
Edinburgh. 

12 February 1992: BT: Money Talks by Robert Millington, 
Barclays de Zoete Wedd. To be held in Room 340, Telephone 
House, Edinburgh. 

12 March 1992: BT—European Leaders by Mike Bett, Vice- 
Chairman, BT. To be held in the Concert Hall, Strathclyde Suite, 
Glasgow, commencing at 15.00 hours. 

15 April 1992: Mobile Communications: The Next Moves by 
Peter Skinner, Director, Mobile Communications. To be held in 
Room 340, Telephone House, Edinburgh. 

Lancs and Cumbria Centre 

All lectures will be held in the Harris Conference Centre, Gar- 
stang Road, Preston, commencing at 14.00 hours, coffee from 
13.30. 

3 December 1991: Tunnel Vision by Paul Falkner and Gerry 
Lyne, project manager and engineer for BT Cordiale, the joint 
venture between BT and France Telecom which has successfully 
tendered for the contract to supply all communication links for 
the Channel Tunnel. The lecture will include a short video 
presentation. 

7 January 1992: Development in Fibre Optic by Dr. Peter Coch¬ 
rane. 

4 February 1992: A Supplier *s View of Telecom by a leading 
manager from GEC Plessey Telecommunications Limited. 
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3 March 1992: The Local Network: More than Poles and Holes 
by Mike Frost, local network manager for Personal Communi¬ 
cations. 

Liverpool Centre 

15 or 22 January 1992: (Date to be confirmed.) Health and Safety 
at Work by Harry Baker, Health and Safety Inspector. To be held 
at Bradford Hotel, Tithebam Street, Liverpool, commencing at 
12.45 hours, buffet from 12.00. 

February 1992: Prestige lecture with Manchester Centre. To be 
announced later. 

March 1992: PCN 2000. To be announced later. 

9 April 1992: The World of Private Services by Sue Davidson, 
General Manager, Private Services, Business Communications. 
To be held at Bradford Hotel, Tithebam Street, Liverpool. 

London Centre 

7 December 1991: Family Christmas Lecture— The Secret Life 
of Machines by Television Presenter Tim Hunkin. To be held at 
The Institution of Electrical Engineers, Savoy Place, London 
WC2R OBL, at 11.00 hours and 14.30 hours. Refreshments 
available 30 minutes before each session. Admission strictly by 
ticket. Free tickets can be obtained by writing to: 1991 Christmas 
Lecture Office, Post Point T125, Telephone House, Shoot up 
Hill, London NW2 3BA enclosing a self-addressed envelope to 
your office address. 

Manchester Centre 

22 January 1992: The Future ofBTs Local Access Network by 
Peter Lisle. To be held at UMIST Staff House, Room 41, com¬ 
mencing at 13.30 hours. 

February 1992: Prestige lecture at Liverpool. To be announced 
later. 

25 March 1991: A Personal View of the BT Engineering Academy 
Programme by Adrian Attwood, Dave Mand and John Oliver. To 
be held at UMIST Renold RBD7, commencing at 13.30 hours. 

Martlesham Heath Centre 

All lectures will be held in the John Bray Lecture Theatre, BT 
Laboratories, Martlesham Heath, commencing at 16.00 hours. 

21 November 1991: Technologies to make the Future Renewable 
by Michael Harper, Friends of the Earth. 

10 December 1991: The Evolving World of Data Communica¬ 
tions by John Atkins, BT Laboratories. 

14 January 1992: The Potent Mix: Communication — Informa¬ 
tion—Regulation by Dr David Leakey, Group Technical Advisor, 
BT. 

North Downs Centre 

All meetings will be from 13.30-15.30 hours. A buffet lunch will 
be provided from 12.30 hours. 

26 November 1991: Payphones — Yesterday , Today and Tomor¬ 
row by Patricia Vaz, General Manager, Customer Service, BT 
Payphones. To be held at The Royal Oak Hotel, Sevenoaks. 

11 December 1991: Two-part lecture, (a) Switch Tactical Plan¬ 
ning by Stewart Penfound, Switch Tactical Planning, Home 
Counties South. ( b) Pole Erection by Martin Sadler, External 
Network Construction, Brighton. To be held at The Boxley 
House Hotel, Maidstone. 

26 February 1992: The Business Customer by Humphrey Pen¬ 
ney, Major Customer Service Manager, Business Communica¬ 
tions Home Counties. To be held at The Boxley House Hotel, 
Maidstone. 
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25 March 1992: A Customer's Perception of BTby Stuart Raven- 
scroft, National Provident Institution. To be held at The Boxley 
House Hotel, Maidstone. 

22 April 1992: The Network Operations Unit by Liam Kelly, 
Network Operations Manager, Home Counties South. To be held 
at the Boxley House Hotel, Maidstone. 

North East Centre 

All meetings will commence at 14.00 hours. 

3 December 1992: Safety Management by Ken Clark, BT Chief 
Safety Officer. To be held at Neville Hall, Newcastle. 

3 February 1992: Tomorrow's Access Network by John Peacock, 
BT Laboratories. To be held at Neville Hall, Newcastle. 

3 March 1992: Malicious Calls Unit by Jessica Newhouse, BT 
Malicious Calls Unit, Canterbury. To be held at Neville Hall, 
Newcastle. 

7 April 1992: Access Network—Alternatives to Copper by Paul 
Rodgerson and Keith Vinning, Fulcrum. To be held at Cleveland 
Scientific Institute, Middlesbrough. 

12 May 1992: Speaker from BT National Advertising Unit. To 
be held at Neville Hall, Newcastle. 

North Wales and the Marches Centre 

11 December 1991: Presentation by Colin Mulcahy, Marketing 
Manager. To be held at Post House Hotel, Chester. 

29 January 1992: Presentation by Tim LeGood, General Man¬ 
ager, Customer Service, Personal Communications Division 
Wales and West. To be held at Beauchamp Hotel, Shrewsbury. 

19 February 1992: Presentation by Bob Lamb, Operations Man¬ 
ager, Wales and West. To be held at Whittington House, Os¬ 
westry. 

10 March 1992: Presentation by John Buttle, Planning Manager, 
Wales and West. Venue to be announced. 


Northern Ireland Centre 

All meetings will be held in the Business Centre, Dial House, 
Belfast, commencing at 12.00 hours. 

11 December 1991: The Competitive Challenge within Northern 
Ireland by Bertie Campbell, BTNI. 

8 January 1992: Finance for BT Engineers by Kieran McPolin 
and Paddy Turnbull, BTNI. 

12 February 1992: Marketing to Personal Customers , by Ian 
Ash, Director of Marketing, PC. 

11 March 1992: Front Office Changes and the Customer Recep¬ 
tion Point by Moore Kennedy, BTNI. 

8 April 1992: The Junction Network System by Simon Kimpton. 

Severnside Centre 

8 January 1992: The Future of Copper in the Access Network by 
Peter Lisle. To be held in the Conference Room, 6th Floor, 
Mercury House, commencing at 14.15 hours. 

5 February 1992: A Glimpse of the Future by Dr. T. Rowbotham, 
Director, Network Technology. To be held in Conference Rooms 
A and B, Ground Floor, Mercury House, commencing at 14.15 
hours. 

23 April 1992: Telecommunications by Bruce Bond, Director, 
Group Products and Services. To be held in the Watershed 
Conference Centre, commencing at 14.15 hours. 
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South Downs Centre 

All meetings will be held at the Worthing Central Library Lecture 
Theatre, Richmond Road, Worthing, preceded with a buffet 
lunch at 12.00 hours and commencing at 12.45 hours. 

3 December 1992: What a Customer Needs from BT by Martin 
Green, Worldwide Communications Manager of American Ex¬ 
press. 

14 January 1992: Flight Simulators by David Parkinson, Singer 
Link Miles Flight Simulators. 

11 February 1992: The NOU/NFU Partnership by Steve Ellett, 
Operations and Surveillance Manager, and Bernard Walker, Net¬ 
work Maintenance Manager Sothem Home Counties West. 

10 March 1992: The Marketing of BT by Ian Ash, Marketing 
Director, BT Personal Communications. 

South Midlands Centre 

15 January 1992: 0+2 Carrier by James Alexander. To be held 
at the Auditorium, Aylesbury Conference Centre, from 13.BO- 

15.30 hours. 

12 February 1992: B.O.A.T.. The introduction of office automat¬ 
ion within BT by Tom Wyman and his team, from Martlesham 
Heath. To be held at the Conference Room, Phoenix House, 
Milton Keynes, from 12.30-14.00 hours, with a buffet at noon. 

April 1992: Bruce Bond will address a combined meeting with 
East Anglia on a topical subject. 

South West Centre 

A buffet lunch will be provided at Exbridge and Telecom House 
lectures. Visitors are required to produce identification on arri¬ 
val. 

15 January 1992: Health and Safety Executive. Presenter to be 
announced. To be held at Ex bridge House, Exeter, from 12.00- 

14.30 hours. 

12 February 1992: Visit to Goonhilly. 

18 March 1992: Title and presenter to be announced. Meeting 
will be held at Telecom House, Plymouth, from 12.00-14.30 
hours. 

Staffordshire Centre 

Except where stated, all meetings will be held at the BT Technical 
College, Stone, commencing at 13.45 hours. 

9 December 1991: Solar Energy and its Applications by Profes¬ 
sor D. Hill, President, UK Solar Energy Society. Joint IEE/IBTE 


meeting commencing at 18.15 hours with a buffet tea at 17.30 
hours. 

13 January 1992: Distance Learning—The State of the Art by 
Margaret Bell, Manager Distance Learning. 

4 February 1992: Training and Enterprise Council—Roles and 
Relationships by Mr. Ward, Chief Executive and Managing 
Director, Staffordshire TEC. 

2 March 1992: Technology Management—The Hidden Compe¬ 
titive Edge by John R Fawn, jrf and associates. 

Thames Valley Centre 

Members will be notified of details. 

19 November 1991: 1992, The Euro Telecomms Manager. 

14 January 1992: Fibre Optics Trials. 

18 February 1992: Team Working. 

17 March 1992: A Customer's View. 

14 April 1992: Integrated Services Digital Network. 

West Midlands Centre 

13 November 1991: A Glimpse of the Future by Dr. Peter 
Cochrane, BT Laboratories. 

January 1992: Work Management. 

February 1992: Network Forum—Finance. 

March 1992: IBTE/FITCE. Telecommunications on the World 
Scene. Congress report back. 

West of Scotland Centre 

11 December 1991: Visit to the network operations unit at 
Woodcroft, Edinburgh, commencing at 14.00 hours. Speaker: 
Charlie Allison. 

22 January 1992: Operation Sovereign 1 YearOnby PaulDuffin. 
To be held at the Glasgow Royal Concert Hall, commencing at 
14.00 hours. 

19 February 1992: Strategy for the Future of the BT Access 
Network by Colin Shurrock. To be held at the Strathclyde In¬ 
stitute, commencing at 12.15 hours. 

12 March 1992: BT—European Leaders by Mike Bett, Vice- 
Chairman, BT. To be held at the Glasgow Royal Concert Hall, 
Strathclyde Suite, commencing at 15.00 hours. 

1 April 1992: The Evolving Network by Alfie Kane. To be held 
at the Strathclyde Institute, commencing at 14.00 hours. 


Notes and Comments 

NEW SUBSCRIPTION RATES—EXTERNAL 
CUSTOMERS 

New subscription rates for the Journal for external customers 
(that is, not employees of BT) will take effect from January 1992. 
The new rates are as follows: 

Price per copy (companies, universities, libraries and other 
bodies): 

£5-00 (£5-75 including postage and packaging UK) 

(£7 00 including postage and packaging overseas) 

Price per copy for private individuals (to be paid for by 
personal cheque): 

£3-50 (£4-25 including postage and packaging UK) 

(£5-50 including postage and packaging overseas) 


One year’s subscription (companies etc.): 

£23 00 UK 
£28 00 Overseas 

One year’s subscription for private individuals (to be paid for 
by personal cheque): 

£17 00 UK 
£2200 Overseas 

Overseas customers can pay by sterling drafts drawn on Lon¬ 
don. Because of high bank charges, payments in US dollars 
cannot be accepted. 
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IBTE LOCAL-CENTRE CONTACTS 


The following is a list of Local-Centre contacts to whom enquiries about the Institution may be directed. Where no Membership 
Secretary details are shown, membership enquiries should be directed to the Local Secretary. 

Centre 

Local Secretary 

Membership Secretary 

Aberdeen 

Jim Martin (0224 752688) 

George Cameron (0224 752857) 

Bletchley/South Midlands 

Jim Coley (0234 274840) 

Keith Sanford (0234 274043) 

East Anglia 

Terry Birdseye (0702 373347) 

Keith Phillips (0206 717244) 

East Midlands 

Dave Bostrom (0533 534212) 

Ian Bethell (0602 478587) 

Lancs & Cumbria 

Trevor Hughes (0706 40840) 


Liverpool 

David Bowe (051-229 3723) 

Clive Maude (051-229 4074) 

London 

Anthony Oodan (071-239 1673) 

Peter Martin (081^456 6007) 

Manchester 

John Halton (061-200 9216) 


Martlesham Heath 

Mike Shaw (0473 645594) 

Ian Gilbert (0473 645500) 

North Downs 

Nick Smith (0227 474823) 


North East 

Pete Barrett (091-222 2304) 

Phil Marley (091-222 2887) 

North Wales & Marches 

Peter Clay (0743 274205) 


Northern Ireland 

David Elliott (0232 240353) 


Scotland East 

Graham Neilson (031-345 4392) 

Alan Dickson (031-226 2000) 

Sevemside 

Ian Davis (0272 206701) 

Dean Shephard (0272 206457) 

South Downs 

Graham Lindsay (0273 222234) 

Roger Henderson (0903 30286) 

South Wales 

Peter Coleman (0222 691622) 


Staffordshire 

Ray Piper (0785 813483) 

Paul Field (0785 762419) 

Thames Valley 

Bob Hooker (0734 562614) 

Dave Prout (0734 501244) 

West Midlands 

Gary Chattaway (0203 228396) 

Paul Jervis (021-233 8162) 

West Scotland 

Graham Wellby (041-220 5049) 

Jill Maxwell (041-220 5837) 

Westward 

Rob Rand (0392 212681) 

Chris Gould (0392 212663) 

Yorks & Lines 

Steve Wood (0532 378316) 

Paul Homcastle (0274 375988) 

ASSOCIATE SECTION INTER-DISTRICT COMMITTEE CONTACTS 

The following is a list of Associate Section Inter-District Committee contact points to whom enquiries about the Associate Section 
should be directed. 

Inter-District Committee 

Contact 

Telephone No. 

London 

John Tythe 

081-804 2400 Ext 460 

Midland 

John Sansom 

0604 35999 

North East 

Keith Whalley 

0642 310937 

Northern Home Counties 

Andy Edmonds 

0473 646414 

Northern Ireland 

Roy Gamble 

0232 621421 

North West 

Phil Holt 

061-600 8111 

Scotland 

Kevin McMonagle 

041-220 2561 

South East 

Martyn Harvey 

0424 436494 

South West 

David Sanders 

0272 260626 

Wales 

Ferg Brown 

0952 49886 
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31st European Telecommunications Congress 

27 September-2 October 1992, Granada, Spain 


CALL FOR PAPERS 


The Federation of the Telecommunications Engineers of the European Community (FITCE) is 
inviting papers for the 31st FITCE Congress on the following theme: 

Telecommunications and the Single European Market’ 

The theme will embrace: 

• The role of telecommunications in economic development and its importance in regional 
development. 

• The need for strengthening telecommunications in the pan-European industrial and 
service sector. 

It is anticipated that each author will be expected to submit an abstract of the proposed paper 
by the end of February 1992. The abstract, of no more than one page, should give a clear 
indication of the theme and coverage of the proposed paper. 

The FITCE Papers Selection Committee is expected to advise authors during early-April 1992, 
after the final programme has been determined. 

The full text of a selected paper should be about 2000 words to allow for a 20 minute 
presentation and 10 minutes for questions and debate. The FITCE Congress Office, at the 
address to be advised later, would expect to receive the full text from the selected authors in 
early-June 1992. 

Prospective authors should contact: Paul Nichols, IBTE Office and Publications Manager, Post 
Point G012, 2-12 Gresham Street, London EC2V 7 AG; Tel: 071-356 8022; Fax: 071-356 7942. 


FITCE MEMBERSHIP 

FITCE is an organisation of national associations with similar objectives to IBTE and draws its members from 
the public telecommunications administrations of Belgium, Denmark, Eire, France, Greece, Italy, Luxemburg, 
the Netherlands, Portugal, Spain, the United Kingdom and Germany. FITCE sponsors multi-national study 
groups (Commissions) to enquire into and report on problems of general interest, and each year one of the 
member countries hosts a General Assembly/Congress at which a given technical theme is discussed. FITCE 
also publishes a journal —FITCE Revue—which is distributed to Members. 

Membership of FITCE is available to Members and Affiliated Members of IBTE who hold a University Science 
Degree and/or are Corporate Members of the Chartered Engineering Institutions and/or are Chartered 
Engineers. 

Further details about FITCE Membership and FITCE Membership Application Forms can be obtained from 
Tapash Ray, UK FITCE Group, Post Point 213, The Angel Centre, 403 St John Street, London EC1V 4PL. 
Telephone: 071-239 0429. 
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RADIO SPECTRUM 
MANAGEMENT 

by D J Withers 

The capacity of the radio spectrum for trouble-free systems is very large, given good 
management, but it is not limitless and new users and new uses for radio are constantly 
emerging. Elaborate measures, involving national spectrum management and international 
regulation of spectrum use, are employed to ensure that the necessary spectrum capacity 
remains available. 

536pp, 229 X 148mm, casebound 
ISBN 0 86341 177 0,1991, £59 

OTHER TITLES AVAILABLE NOW 

• Satellite communication systems 2, edited by B. G. Evans 
564pp, 229 X 148mm, casebound, ISBN 0 86341 229 7,1991, £59 

• Personal and mobile radio systems, edited by R. C. V. Macario 
329pp, 229 X 148mm, casebound, ISBN 0 86341 219 X, 1991, £46 

• The third way: telecommunications and the environment 
State-of-the-art digest 3, by J. Harper 

72pp, 210 X 148mm, paperback, ISBN 0 86341 235 1,1990, £10 

• Data communications and networks 2, edited by R. L. Brewster 
182pp, 229 X 148mm, casebound, ISBN 0 86341 190 8,1989, £42 

• SPC digital telephone exchanges, by E J. Redmill and A. R. Valdar 
497pp, 229 X 148mm, casebound, ISBN 0 86341 147 9,1990, £60 

• Common-channel signalling, by R. j. Manterfield 

252pp., 229 X 148mm, casebound, ISBN 0 86341 240 8,1991, £38 

• Transmission systems, edited by J. E. Flood and P. Cochrane 
530pp., 229 X 148mm, casebound, ISBN 0 86341 148 7,1991, £59 


ORDER FROM: 

I EE, PO Box 96, Michael Faraday House, Six Hills Way, Stevenage, Herts. SGI 2SD, UK. 
Tel. (0438) 313311, Fax (0438) 742792. 

Q Please send me _1_ copy/copies of -- 


Please send me the 1992 Publications Catalogue 

Name__ 

Address- 


Date_ 

I enclose a cheque for £ 
(made payable to IEE) 


Signature - 

Q] Please invoice me. Order no. 



IEE 


Prices include postage within the UK. Outside the UK, customers should add 10% of the total price to cover 
postage by PrintFlow Air to Europe. Outside Europe, 15% should be added to the price to cover postage by 
PrintFlow Air Saver. Airmail rates are available on request. Credit card orders (Access and Visa) are considered 
prepaid and will be accepted by telephone on (0438) 313311. Invoices for orders that are not prepaid will 
include a handling and package charge of £1.50 per book (maximum £6). 






























